IRC log for #oe on 20100630

00:05.52*** join/#oe BenLauDC (~benlau@221.125.8.44)
00:06.49CIA-203Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r46a631a298 10openembedded.git/recipes/ (kexecboot/linux-kexecboot_git.bb linux/linux_git.bb):
00:06.49CIA-2linux(-kexecboot): bump SRCREV for git recipe and decrease D_P a bit more
00:06.49CIA-2Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
00:11.59*** join/#oe htns (~htns@61.6.64.6)
00:52.03*** join/#oe sicu_ (~sicu@ti0090a380-dhcp0813.bb.online.no)
00:54.50*** join/#oe Leatherface (~leatherfa@dreambox.pite.biz)
01:03.02*** join/#oe zecke (~ich@123.192.240.117)
01:19.34*** join/#oe methril__ (~methril@189.27.135.72.dynamic.adsl.gvt.net.br)
01:45.12*** join/#oe playya (~playya@unaffiliated/playya)
01:49.37*** join/#oe mekius (~mekius@enlightenment/developer/mekius)
01:50.38*** join/#oe GNUtoo|laptop (~gnutoo@95.237.131.90)
02:09.46*** join/#oe playya (~playya@unaffiliated/playya)
02:35.32*** join/#oe zecke (~ich@123.192.240.117)
03:14.33*** join/#oe borg__ (~olaf@p5486944D.dip0.t-ipconnect.de)
03:21.12*** join/#oe cdbot2 (~cdbot2@hentges.net)
03:29.53*** join/#oe htns (~htns@61.6.64.6)
04:01.08*** part/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net)
04:03.32*** join/#oe d_t_h (~dieter@a89-182-129-143.net-htp.de)
04:03.36*** join/#oe otavio (~otavio@debian/developer/otavio)
05:07.39*** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net)
05:08.02*** join/#oe mrc3_ (~mrc3@nat/ti/x-pmsqivedqdvdqqmu)
05:15.43*** join/#oe IgorK (~igor@user-64-9-236-245.googlewifi.com)
05:16.34*** join/#oe mrc3_ (~mrc3@nat/ti/x-aczgmehqiabewiql)
05:33.35*** join/#oe CMoH-notebook (~cipi@95.76.71.81)
06:05.59CIA-203sledz <sledz@ba11ecae-741b-462f-8724-1218f99f5906> 07org.openembedded.dev * rc45b19daad 10openembedded.git/recipes/linux/linux-2.6.24/hipox/defconfig:
06:05.59CIA-2linux-2.6.24: enable DEBUG_FS and USB_MON for hipox machine
06:05.59CIA-2Signed-off-by: Steffen Sledz <sledz@dresearch.de>
06:05.59CIA-2git-svn-id: https://svn.dresearch.de/repos/openembedded/branches/2010-02-24_initial@92 ba11ecae-741b-462f-8724-1218f99f5906
06:19.46*** join/#oe kevinsc (~a0214685@nat/ti/x-jywtsfgijdpjhhkp)
06:28.13*** join/#oe thebohemian (~rschus@p5DDC348B.dip.t-dialin.net)
06:31.44*** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com)
06:32.13*** join/#oe jmpdelos_ (~polk@outgoing.delos.com)
06:36.41*** join/#oe B_Lizzard (~havoc@athedsl-432863.home.otenet.gr)
06:50.51*** join/#oe vps (~vitus@212.144.247.210)
06:51.34eFfeM_workhm, would have expected that the unpack stage would already copy the patches to the workdir (but not apply them), is it a bug or a feature that this does not happen?
06:55.28*** join/#oe nlCortana (~johan@ip45-216-212-87.adsl2.static.versatel.nl)
07:05.01*** join/#oe Proxyles (~henrik@c-f893e255.56-4-64736c14.cust.bredbandsbolaget.se)
07:10.54*** join/#oe B_Lizzard (~havoc@athedsl-432863.home.otenet.gr)
07:11.15JaMaeFfeM_work: it works like this for me (I have them in ${WORKDIR} after -c unpack)
07:11.45eFfeM_workhm, just tried it for gcc-cross-intermediate and they were not there
07:11.59*** join/#oe cyberdeck (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de)
07:12.25eFfeM_workwanted to have them copied then quilt push them until I hit the one that needed a patch, now did -c patch and popped back
07:12.32eFfeM_workbut was kinda surprised by this
07:12.35eFfeM_workwill retry
07:19.36*** join/#oe Jay7 (jay@95-29-184-203.broadband.corbina.ru)
07:19.59*** join/#oe pb__ (~pb@blundell.swaffham-prior.co.uk)
07:25.03eFfeM_workbtw is there a way to force printing a message when a certain machine is used when baking things? for nios2 I would like to print a message where to find the actual cpu file
07:25.27eFfeM_workalternative is probably to have a readme or to add comment in the machine conf file
07:31.08*** join/#oe CMoH (~cipi@95.76.71.81)
07:39.39*** join/#oe sgh (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk)
07:46.59*** join/#oe denix_ (~denix@pool-71-251-56-71.washdc.east.verizon.net)
07:49.42*** join/#oe CMoH (~cipi@95.76.71.81)
07:49.50hrwmorning
07:53.49*** join/#oe sgh (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk)
07:59.35*** join/#oe screwgoth (~raseel@122.170.117.98)
08:17.59*** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian)
08:18.37*** join/#oe rob_w (~bob@pD95EDB8C.dip.t-dialin.net)
08:21.15*** join/#oe woglinde (~henning@p5DDC348B.dip.t-dialin.net)
08:22.51floriangood morning
08:27.35woglindehi florian
08:29.35*** join/#oe kristoffer (~kristoffe@109.58.76.145.bredband.tre.se)
08:32.21*** join/#oe ant_work (~andrea@host214-85-static.34-85-b.business.telecomitalia.it)
08:36.02*** join/#oe vivijim (~rvivi@pasanda.collabora.co.uk)
08:36.39*** join/#oe raster (raster@enlightenment/developer/raster)
08:50.10CIA-203Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * r748d27503b 10openembedded.git/recipes/llvm/llvm2.7_2.7.bb: llvm2.7 2.7: Split packages for each shared library.
08:50.19woglindejo raster
08:50.24CIA-203Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * r3a0f681008 10openembedded.git/recipes/llvm/ (9 files in 3 dirs): llvm: Removed 2.5 and 2.6 and both native variants.
08:50.25CIA-203Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * r06be7fc026 10openembedded.git/recipes/llvm/ (llvm-native.inc llvm.inc llvm2.7_2.7.bb): llvm.inc: Moved packages dynamic stuff into the general llvm.inc file.
08:59.47rasterwoglinde:  poop!
09:15.48woglindehi mrmoku
09:17.33mrmokuhi woglinde
09:22.57*** join/#oe mickey|w701 (~mickey@e180162184.adsl.alicedsl.de)
09:23.36CIA-203Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r723a7c8b21 10openembedded.git/recipes/xorg-driver/ (2 files in 2 dirs):
09:23.36CIA-2xf86-video-glamo: better patch for nonDRM kernels
09:23.36CIA-2Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
09:23.37CIA-203Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rc2c6f15e59 10openembedded.git/recipes/xorg-xserver/ (2 files in 2 dirs):
09:23.37CIA-2xserver-xorg-1.8.99.903: update patch for freedesktop #28824
09:23.37CIA-2* https://bugs.freedesktop.org/show_bug.cgi?id=28824
09:23.37CIA-2Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
09:35.36*** join/#oe ZeeD (~ZeeD@80.252.210.136)
09:35.41*** join/#oe GNUtoo|laptop (~gnutoo@95.237.131.90)
09:36.51woglindehi gnutoo
09:39.03*** join/#oe zecke (~ich@123.192.240.117)
09:39.31*** join/#oe jmpdelos (~polk@outgoing.delos.com)
09:39.52GNUtoo|laptopwoglinde, hi
09:54.09*** join/#oe dth_ntb (~dieter@a89-183-65-193.net-htp.de)
10:02.02*** join/#oe kergoth (~kergoth@ip24-251-170-95.ph.ph.cox.net)
10:04.02*** join/#oe screwgoth (~raseel@122.170.20.171)
10:23.56woglindejo kergoth
10:28.21*** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho)
10:29.25*** join/#oe CMoH (~cipi@95.76.71.81)
10:29.31*** join/#oe playya (~playya@unaffiliated/playya)
10:30.42*** join/#oe zecke (~ich@123.192.240.117)
10:34.37*** join/#oe hillct_ (~hillct@cpe-069-134-161-218.nc.res.rr.com)
10:36.52*** join/#oe mickeyl (~mickey@openmoko/coreteam/mickey)
10:52.16blindvt`khem, ping?
10:54.00*** join/#oe methril_work (~rafael@201.35.65.90)
10:58.31*** join/#oe jmpdelos_ (~polk@outgoing.delos.com)
11:03.06CIA-203Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r58cdf0ae06 10openembedded.git/recipes/openmoko-3rdparty/mcnavi_0.2.10.bb:
11:03.06CIA-2mcnavi: add 0.2.10
11:03.06CIA-2Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
11:12.44*** join/#oe kristoffer (~kristoffe@95.209.68.226.bredband.tre.se)
11:16.39*** join/#oe Nikunj (7d166140@gateway/web/freenode/ip.125.22.97.64)
11:17.18CIA-203Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * rd5be18abe1 10openembedded.git/recipes/llvm/llvm2.7_2.7.bb: llvm2.7 2.7: Changed patch URL to new format.
11:18.14NikunjHi All, one doubt pls.. bitbake only uses Internet for downloading sources tars and zips. ?? and no other purpose!!?
11:19.17thebohemianNikunj: and tinderbox if you have activated that
11:20.09thebohemianand its not bitbake which accesses the net to retrieve sources but the programs that are needed to fetch a particular URI (eg. a SVN, GIT or HG repository)
11:21.22Nikunjthebohemian: Thanks for the info, but if I want to restrict bitbake to use only whatever is present on the system ( the sources/ folder )and dnt look on the net..what can be done here then.?
11:21.45Nikunjthebohemian: and how bad is goin in this way.?
11:22.16thebohemianNikunj: one way is to only run the tasks that fetch the sources once
11:22.26*** join/#oe julianpid (~julianpid@firewall.ctxuk.citrix.com)
11:22.37thebohemianwhen that finishes the next run will not fetch any sources from the net
11:22.58thebohemian(provided you do not change the metadata in between, e.g. git pull)
11:23.17JaMabut will ask VCS servers for latest revs if ie AUTOREV is used in some recipe
11:23.27mwester(yuck)
11:23.45*** join/#oe aditya_111 (~Aditya@c-69-143-196-44.hsd1.md.comcast.net)
11:24.42Nikunjthebohemian: hmm..that means, If I unplug network cable and start bitbaking.. ( Assuming my sources/ folder has all needed tars and zips ) the chances that my run will be successful is as good as with network cable.?
11:25.28thebohemianNikunj: I think so, yes
11:25.57Nikunjthebohemian : Thts great..!! :-)
11:54.07*** join/#oe hrw (~hrw@chello089078170228.chello.pl)
11:56.47woglindehi hrw
11:57.08hrwre
11:57.35woglindehrw could you please ack the patches from stefan?
11:57.39woglindefor stable
11:59.09hrwwill look
12:00.02hrwecj acked - something more?
12:01.06woglindehm
12:01.15woglindedamn
12:01.20woglindegcc isnt complete yet
12:01.24woglindewill talk with stefan
12:01.24blindvt`khem, uclibc.org/~aldot/uClibc/nptl/
12:03.46CIA-203Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r52ebbfaf6c 10openembedded.git/recipes/jamvm/jamvm-initial_1.4.5.bb: jamvm-initial 1.4.5: fix dependencies, see http://tinderbox.openembedded.org/public/logs/task/6388490.txt
12:05.41CIA-203Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r81adc0e1ce 10openembedded.git/recipes/xbmc/xbmc_svn.bb: xbmc: fix version and fixup python lib
12:15.35*** join/#oe thebohemian (~rschus@p5DDC348B.dip.t-dialin.net)
12:18.54*** join/#oe konne6423 (~Miranda@85.183.99.11)
12:18.59*** join/#oe vivijim (~rvivi@pasanda.collabora.co.uk)
12:20.36*** join/#oe vivijim (~rvivi@pasanda.collabora.co.uk)
12:20.36*** join/#oe bitkiller (~bitkiller@187.59.10.35)
12:36.45*** join/#oe linf (~lint@c906a103.virtua.com.br)
12:47.36*** join/#oe mickey|w701 (~mickey@e180162184.adsl.alicedsl.de)
13:06.35*** join/#oe CMoH-notebook (~cipi@89.238.251.90)
13:08.40*** join/#oe aloisiojr (~aloisio@200.184.118.136)
13:09.08CIA-203Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * r40171e8aa6 10openembedded.git/recipes/libxsettings-client/ (4 files):
13:09.08CIA-2libxsettings-client: switch to using INC_PR
13:09.08CIA-2Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
13:09.09CIA-203Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * r23d51f646b 10openembedded.git/recipes/libxsettings-client/libxsettings-client.inc:
13:09.09CIA-2libxsettings-client: use xsettings-common.h from libxsettings-dev
13:09.09CIA-2Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
13:09.11CIA-203Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * re90cf71fe6 10openembedded.git/recipes/xcb/ (xcb-proto.inc xcb-proto_1.6.bb):
13:09.16*** join/#oe etrunko (~edulima@187.75.148.141)
13:13.40*** join/#oe kristoffer (~kristoffe@109.58.53.185.bredband.tre.se)
13:15.48*** join/#oe dos11 (~dos@unaffiliated/dos1)
13:16.20eFfeM_workcan I extend FILESPATHPKG based upon architecuture? e.g. FILESPATHPKG_nios2 += "glibc-2.5:files:"
13:16.24eFfeM_work?
13:20.03zeckeeFfeM_work: yes, but why?
13:20.53eFfeM_workzecke: just tested it, apparently it does not work, if I remove the _nios2 part it does work
13:21.35eFfeM_workzecke: nios2 needs some additional glibc patches for 2.5 but apparently all patches from 2.5 are taken from the glibc-2.4 dir
13:22.04woglindeeffem use add
13:22.40eFfeM_workwoglinde add? or append? FILESPATHPKG_add_nios2 ?
13:23.15eFfeM_workactually glib2.5 defines FILESDIR, doesn't seem to sue FILESPATHPKG
13:23.30eFfeM_workglibc
13:23.41eFfeM_workthis is somewhat of a mess
13:28.32eFfeM_workanyway, got it going: FILESPATHPKG_nios2 = "glibc-2.5:glibc-2.4:files:"
13:29.02*** join/#oe aloisiojr (~aloisio@200.184.118.130)
13:29.04eFfeM_worknot the nicest solution but as people feel 2.5 should get its files from the 2.4 dir this seems the best I can do
13:29.16woglindehm
13:29.35woglindeI think nobody really cared about this all
13:29.41woglindeand nobody cleaned it up
13:30.14eFfeM_worki coined it on the ML, did get some negative feedback :-( will paste url
13:32.47woglindeeffem best would be nios could take a actual libc
13:32.49eFfeM_workactually it was not mailed as such, my original msg was in http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-June/020963.html
13:32.53woglindean
13:32.56woglindeor uclibc
13:33.19eFfeM_workmight be someone here mentioned that 2.5 referred to 2.4 to save some space
13:33.32eFfeM_workwoglinde: I understand and share your feelings. This is on the todo list
13:33.59eFfeM_workbasically there is a nios2 git and that one has 2.5; will try a later version at a later tiem
13:36.43*** join/#oe bitkiller (~bitkiller@187.112.159.244)
13:38.18*** join/#oe rsalveti (~rsalveti@200.184.118.136)
13:39.38eFfeM_work(btw tried uclibc for nios2+mmu but that needed some work,might also peek at eglibc); want to upgrade binutils (and maybe gcc) first
13:41.00*** join/#oe playya_ (~playya@unaffiliated/playya)
13:41.02*** join/#oe rsalveti (~rsalveti@200.184.118.136)
13:44.13woglindeeffem a lot of work to do
13:46.28*** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net)
13:46.55eFfeM_workwoglinde: yes; I'm already happy that I got the stuff building based upon standard releases i.s.o. windriver/csl stuff
13:48.03eFfeM_worklatest binutils is probably mostly done
13:48.31woglindehehe
13:49.00eFfeM_workgcc will be a pain, might have chagnes to go to 4.2, but 4.4 still gave a lot of issues
13:50.14woglindeI hope you get paid well
13:51.45eFfeM_workhmm. that is not too bad but my boss is already happy if we have it runnign and is not too interested in moving to the latest gcc etc
13:52.16eFfeM_worklearned a lot about gcc machine descriptions recently, trying to find out why things work on 32bit but not on 64bit
13:53.17*** join/#oe linf (~lint@c906a103.virtua.com.br)
13:53.17woglindeeffem sure
13:56.09eFfeM_workpart of the fun ...
14:12.39kergothhah, i forgot that originally referencing a var that didn't exist was an error.  zecke added it, "VarExpandError" was raised in that case back in the original expansion code
14:14.47*** join/#oe mgrundy (~buglabs@firebug.buglabs.net)
14:15.22woglinde*g*
14:16.45kergoththinks itd be nice to do that again :)
14:28.04*** join/#oe CMoH|office (~cipi@89.238.251.90)
14:31.12*** join/#oe tmartins (~zero@187.37.68.5)
14:34.09*** part/#oe screwgoth (~raseel@122.170.20.171)
14:34.47*** join/#oe digitalmind (~mibbit_he@122.171.16.11)
15:03.22*** join/#oe BenLauDC (~benlau@221.125.8.44)
15:06.28*** join/#oe otavio (~otavio@debian/developer/otavio)
15:21.06*** join/#oe dth_ntb (~dieter@a89-182-129-143.net-htp.de)
15:30.53*** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net)
15:31.06*** join/#oe mrc3_ (~mrc3@nat/ti/x-sajlrorkxsijlubw)
15:57.01*** join/#oe julianpid (~julianpid@62.200.22.2)
16:05.57newbie_sreddyhi all
16:06.39woglindehi
16:07.32newbie_sreddyi had built a custom kernel with external toolchain ... but when loading the image using uboot it give "  BOOTING IMAGE AT  xxxx ....BAD MAGIc number  " s
16:07.52newbie_sreddycan some one let me know what could be th erason
16:09.56woglindewrong kernel config?
16:10.10newbie_sreddyill check that
16:10.12woglindeyou didnt create an uImage
16:10.21newbie_sreddyi created an uImage
16:10.25woglindeokay
16:10.27newbie_sreddyfrom ZImage
16:14.28*** join/#oe awozniak (~awozniak@adsl-76-205-222-173.dsl.snlo01.sbcglobal.net)
16:16.57*** join/#oe gnutoo (~gnutoo@95.237.131.90)
16:17.40khemnewbie_sreddy: and how did you build uImage ?
16:17.57khemdid you use kernel make target
16:19.17newbie_sreddyi build using makeimage tool form my toolchain
16:20.07blindvt`khem, hi. see above for the *patch we talked about yesterday
16:20.40newbie_sreddyi just compiled the kernel using OE  to zImage    .. but after that using the using tool chain I created the UImage
16:21.21woglindeso you dont needed oe at all
16:22.23newbie_sreddyfinally i need .... it but as of now for tesing I am using OE  upto do_compile task
16:23.10khemnewbie_sreddy: and you are sure that you did the right thing
16:23.37khemblindvt: hmm those look invasive
16:24.03khemblindvt: btw noq I feel better after fixing errno on mips.
16:24.22woglindekhem hehe
16:24.26blindvt`khem, they don't just look like ;P
16:24.32newbie_sreddyI will check once again ... is there anything which i should look into apart from kernel configuration and using of correct toolchains ?
16:25.12*** join/#oe toi (~toi@d54C2AA76.access.telenet.be)
16:28.38blindvt`khem, yea, thanks alot for that.
16:28.39*** join/#oe CosmicPenguin (~nobody@129-46-14-212.qualcomm.com)
16:31.05*** join/#oe mrc3_ (~mrc3@nat/ti/x-flbcepshqiqwmxat)
16:40.07*** join/#oe dth_ntb (~dieter@a89-182-129-143.net-htp.de)
16:42.02kergothRP: ping
16:50.51*** join/#oe julianpid (~julianpid@firewall.ctxuk.citrix.com)
16:54.57woglindehm sed guru here
16:55.18woglindeI want to place a newline containing stuff before the string I am searching
16:56.52kergoth"place"? as in, include a newline in the replacement text?
16:57.19woglindehm now
16:57.22woglindeups now
16:57.25woglindeargs no
16:57.39woglindeI want find the string and place line above this string
16:57.54kergoththat doesn't make it any clearer :)
16:57.58kergothelaborate or give an example please
16:58.12woglindeI want find foo somewhere in the file
16:58.34woglindeand one line before foo I want make a newline with some stuff
16:59.00kergothso yes, you want to include a newline in the replacement text
16:59.07kergothyou want to find foo and replace it with newline, some stuff, foo
16:59.15kergothno?
16:59.21woglindeah good idea
16:59.31woglindenow its clear
16:59.36woglindehow it will work
16:59.38woglindethanks
16:59.57kergothnot sure offhand if it'd be easy to do, but i'd think something like s/foo/\nbar\nfoo/ or perhaps \r instead..
17:00.10kergothif that doesn't work, i think theres other ways, but thats worth trying first
17:00.57woglindeyes worked
17:01.01woglindewith grouping
17:01.20woglindesed -i -e "s|\(^sdf*\)|foo\n\1\n|" testfile.txt
17:01.55kergothnice
17:02.27woglindehm the seconde \n is unecessary
17:04.16woglindehm cool
17:15.59*** join/#oe nitin (~nitin@nat/intel/x-heutzrmjodrtywik)
17:29.56*** join/#oe LeTama (~IceChat7@vau06-1-82-228-252-90.fbx.proxad.net)
17:31.54*** join/#oe bluelightning (~bluelight@93-96-131-185.zone4.bethere.co.uk)
17:31.54*** join/#oe bluelightning (~bluelight@pdpc/supporter/professional/bluelightning)
17:32.05*** join/#oe mickey|zzZZzz (~mickey@80.81.242.146)
17:37.37*** join/#oe eFfeM (~frans@j200125.upc-j.chello.nl)
17:42.10Gaston|HomeI deleted a bunch of images for my machine and would like to rebuild the uImage again, what recipe would i need to clean to make that happen?
17:42.37woglinde????
17:43.01woglindeuImage is the wrapped z or bzImage
17:43.09woglindea normal image contains filesystem
17:43.24woglindeand maybee the uImage
17:43.36Gaston|Homeyes, I'd like to get the packaged kernel rebuilt
17:43.49Gaston|Homeas uImage
17:45.06Gaston|HomeDo I make sence?
17:45.15woglindeyes
17:45.43woglindehm uImage is only generated when makeing an normal image
17:45.43*** join/#oe mrc3_ (~mrc3@nat/ti/x-aidftsrttswopwos)
17:45.55Gaston|Homeso I tried bitbake -c clean console-image, and as you know it doesnt really clean deep enough
17:46.08woglindesure its doing
17:46.17woglindedelete stuff under delpoy
17:46.21woglindeimages
17:46.46woglinderun bitbake console-image again
17:47.54woglindeafter bitbake -c clean console-image
17:50.33Gaston|Homethats how it started, I deleted a bunch of old images. Then I tried to clean console-image and rebuilt it
17:50.53Gaston|HomeI guess I'll try to clean the kernel somehow
17:50.55khemkergoth: I want to setup a clone of a git repo but so that I could share it internally do have some advise for me
17:51.43khemkergoth: I still want the repo to be pulled from community repo but publish the internal repo so people can clone it. it wil also have few internal patches
17:51.44*** join/#oe eFfeM (~frans@j200125.upc-j.chello.nl)
17:51.47khemon top
17:51.54*** join/#oe BenLauDC (~benlau@221.125.8.44)
17:58.02woglindedamn
17:58.05woglindedamn
17:58.12woglindedepenendcy stuff
17:58.19woglindewhy I am not allowed
17:58.47woglindeto use packages without ${PN}
17:58.51woglindepackage
18:02.28*** join/#oe CMoH-notebook (~cipi@95.76.71.81)
18:04.00*** join/#oe jcrouse (~nobody@207-114-132-30.static.twtelecom.net)
18:05.29*** join/#oe Crofton (~balister@p5B38D142.dip.t-dialin.net)
18:06.04woglindehe crofton
18:06.15woglindeyou are in germany?
18:06.20kergothwoglinde, what do you mean use packages without ${PN}?
18:06.32Croftonyeah
18:06.38CroftonFriedrichstafen ...
18:07.02woglindekergoth I want PACKAGES = "${PN}-dev ${PN}-dbg ${PN}-doc "
18:07.07woglindea nd
18:07.15woglindePACKAGES_DYNAMIC = "llvm-*"
18:07.27khemFriedrichstafen is a cool place
18:07.43khemCrofton: I use to go there quite a lot
18:07.43woglindebeacause ${PN} make not really sin for llvm
18:07.57kergothwoglinde, would probably have to tweak RDEPENDS_${PN}-{dev,doc,dbg}, make sure they don't depend on ${PN}
18:07.57Croftoncool
18:08.07CroftonI am going to the flying museums in the morning
18:08.07woglindebut the ACKAGES_DYNAMIC = "llvm-*" depneds on ${PN}
18:08.15kergothhmm
18:08.15woglindeeven it isnt there
18:08.18khemCrofton: you should also go to bodensee
18:08.22CroftonFly out of Frankfurt friday mornuing
18:08.29Croftonthat is the water thing
18:08.37Croftonneed to go outside and look around
18:08.43woglindeI am now try to work around it with empty ${PN}
18:08.47Croftonand get of interweb until is it dark :)
18:08.50Croftonbye guys
18:08.53Croftonthanks for the tips
18:09.00khemCrofton: enjoy
18:09.07woglindebye crofton drink some beer
18:09.22Croftonwoglinde, of course :)
18:09.52khemCrofton: ulmer muenster :)
18:10.46woglindesigh
18:10.55woglindeand the ${PN} depends on all PACKAGES_DYNAMIC = "llvm-*" even its empty
18:11.36woglindeor the index generator suckz
18:11.56woglindeargs
18:14.23*** part/#oe IgorK (~igor@user-64-9-236-245.googlewifi.com)
18:15.48woglindekergoth any idea?
18:20.29woglindehm okay
18:20.37woglindefixed now
18:24.59*** join/#oe florian (~fuchs@Maemo/community/contributor/florian)
18:25.06woglindere florian
18:25.16florianre
18:30.15*** join/#oe dos11 (~dos@unaffiliated/dos1)
18:45.31*** join/#oe Angelox_123 (~root@201-95-46-43.dsl.telesp.net.br)
18:45.44Angelox_123Its slow the compilation?
18:46.02woglinde?????
18:46.04khemslow is relative term
18:46.07woglindedont chat as root
18:46.11woglindeyou might get hacked
18:46.22Angelox_123i am using slackware....
18:46.36woglindedont depends on the host distro
18:46.41woglindedepends only on hw
18:46.42Angelox_123and i cannot use another user to chat....
18:46.49woglindesure you can
18:46.56woglindesu - newuser
18:46.58Angelox_123i get a error.....
18:47.06woglindeadduser newuser
18:47.23khemwell you get hacked thats your headache isnt it :)
18:47.33khemwhats your problem with OE
18:47.56Angelox_123none...but is slow to compile.....
18:48.08Angelox_123task 194 of 3274
18:48.11khemwhats your build box configs
18:48.33Angelox_123I using P4 1gb Memory
18:48.50woglindethats a slow machine
18:49.09woglindewe are building libc twice and gcc third
18:49.17khemyes I have one of those too and OE has made me think its worthless so I gave it away to kids to play
18:50.02Angelox_123hum.....Whats machine is good for this job?
18:50.16woglinde4-qay
18:50.22woglindeups 4-way
18:50.26woglindebye for now
18:51.07Angelox_123Have any rootfs opeenbbeed of a1200 to download
18:51.13Angelox_123?????
18:51.14khemAngelox_123: people have core i7
18:51.22Angelox_123Wow!!
18:51.41khemAngelox_123: you mean prebuilt
18:51.41CIA-203Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r1f1a416035 10openembedded.git/recipes/xbmc/xbmc_svn.bb: xbmc: add missing deps, bump SRCREV
18:52.07Angelox_123yes khem
18:53.49khemAngelox_123: I dont know off hand
18:54.12khemAngelox_123: OE is about building yourself :)
18:54.20Angelox_123Hum.....
18:55.07Angelox_123what a pity.....
18:56.07CIA-203Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r48dfe40e52 10openembedded.git/contrib/qemu/run-qemu.sh:
18:56.07CIA-2contrib/qemu/run-qemu.sh: Dont search for hdimage when doing a nfsboot
18:56.07CIA-2Signed-off-by: Khem Raj <raj.khem@gmail.com>
19:06.09*** join/#oe Spz0 (~a@97-120-163-154.ptld.qwest.net)
19:09.18*** join/#oe Leatherface (~leatherfa@dreambox.pite.biz)
19:18.22*** join/#oe CMoH (~cipi@95.76.71.81)
19:22.03*** part/#oe jkridner1 (~a0321898@nat/ti/x-tasvfeafynawvsdh)
19:55.47*** join/#oe aloisiojr (~aloisio@200.184.118.130)
19:55.50*** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net)
20:11.19*** join/#oe ZeeD (~ZeeD@80.252.210.136)
20:12.16CIA-203Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * r866fc2f108 10openembedded.git/recipes/libxsettings/libxsettings_0.11.bb:
20:12.17CIA-2libxsettings: bump PR to force rebuild to restore xsettings-common.h in sysroots
20:12.17CIA-2Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
20:13.54*** join/#oe DHR (~hugh@CPE00606767ed59-CM000f9fa81660.cpe.net.cable.rogers.com)
20:16.07*** join/#oe MWelchUK_work__ (~welchma@65.91.2.71)
20:19.31*** join/#oe Crofton (~balister@p5B38D142.dip.t-dialin.net)
20:31.08*** join/#oe mrc3_ (~mrc3@nat/ti/x-wnxbhervssmzconr)
20:51.40CIA-203Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r48cbac51b7 10openembedded.git/conf/distro/include/sane-srcrevs.inc:
20:51.40CIA-2EFL: bump SRCREV a bit more for tasn's fix for Arabic shaping
20:51.40CIA-2Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
20:51.42CIA-203Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r6e70d7daf1 10openembedded.git/recipes/xorg-driver/ (2 files in 2 dirs): xf86-video-glamo: bump SRCREV, remove applied patch
20:55.43*** join/#oe CMoH (~cipi@95.76.71.81)
21:02.35*** join/#oe bluelightning_ (~bluelight@pdpc/supporter/professional/bluelightning)
21:04.40*** join/#oe lisppaste (~lisppaste@common-lisp.net)
21:08.10*** join/#oe likewise (~likewise@82-170-243-215.ip.telfort.nl)
21:14.00*** join/#oe methril_work (~rafael@201.35.65.90)
21:22.40*** join/#oe hansdampf (~moritz@212.77.183.247)
21:31.25*** join/#oe mrc3_ (~mrc3@nat/ti/x-clkidjdsbycagceb)
21:31.35*** join/#oe ant__ (~andrea@host96-74-dynamic.5-87-r.retail.telecomitalia.it)
21:34.09*** join/#oe bitkiller (~bitkiller@187.59.72.143)
21:36.30*** join/#oe ant__ (~andrea@host96-74-dynamic.5-87-r.retail.telecomitalia.it)
21:39.56*** join/#oe bkinman (~bkinman@soenat3.cse.ucsc.edu)
21:40.52CIA-203Klaus Kurzmann <mok@fluxnetz.de> 07org.openembedded.dev * r6918af9576 10openembedded.git/recipes/linux/ (2 files in 2 dirs):
21:40.52CIA-2linux-openmoko-2.6.32_git.bb: add a patch to make jack input events work
21:40.52CIA-2Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
21:41.08*** join/#oe CMoH-notebook (~cipi@95.76.71.81)
21:41.57bkinmanHeya guys! My ship is sinking! So, im building openembedded for the gumstix overo, and my hard drive space is quickly dwindling! I added rm_work or whatever to my local.conf, which is supposed to cut down on space, and ran bitbake to build my distribution again, but it seems that it didn't actually go about cleaning up whatever files are taking up all of the space before it went to compile all over again... Help me #oe, your my only hope!
21:42.49ant__you could try rebuilding from packaged staging
21:43.05ant__remove all in your tmpdir BUT /pstage
21:43.12bkinmanthanks!
21:43.25ant__keep /pstage !
21:44.42bkinmanWhat does rm_work do anyways?
21:45.24ant__it does remove the files in workdir but being the packages are staged (Already compiled once) these are left untouched...
21:45.48ant__thus, rebuilding is needed
21:46.45bkinmanwow, so if i rm_work, that means that every time i build an image, i will have to wait 12 hours?
21:47.12ant__well, only on first build
21:47.23ant__from pstage should be much more rapid
21:47.42ant__i.e. 15mins vs. 2 hours
21:48.01ant__in my case on my host
21:48.22ant__s/should be/is/
21:49.25bkinmangotcha
22:00.57*** join/#oe methril__ (~methril@189.27.134.34.dynamic.adsl.gvt.net.br)
22:04.36*** join/#oe mickey|zzZZzz (~mickey@80.81.242.146)
22:05.47*** join/#oe Lint (~Linp@201-92-183-142.dsl.telesp.net.br)
22:06.26*** join/#oe woglinde (~woglinde@f052065223.adsl.alicedsl.de)
22:08.37*** join/#oe ant__ (~andrea@host96-74-dynamic.5-87-r.retail.telecomitalia.it)
22:08.37*** join/#oe hansdampf (~moritz@212.77.183.247)
22:08.37*** join/#oe Leatherface (~leatherfa@dreambox.pite.biz)
22:08.37*** join/#oe buZz (~buzz@bydogen.stoned-it.com)
22:08.37*** join/#oe chouimat|away (~mathieu@kde/developer/chouinard)
22:08.37*** join/#oe jkridner (~jason@pdpc/supporter/active/jkridner)
22:08.37*** join/#oe sge (~username@62.240.71.4)
22:09.02*** join/#oe buZz (~buzz@bydogen.stoned-it.com)
22:09.07khembkinman: another thinh to change is the debug option
22:09.59*** join/#oe ant__ (~andrea@host96-74-dynamic.5-87-r.retail.telecomitalia.it)
22:10.05woglindere ant
22:10.21khembkinman: I think its using -g3 at the moment and it will eat up your harddisk
22:10.30khemant__: hello
22:10.34ant__hwy woglinde ...bah.. netsplit
22:11.14ant__hello khem
22:11.14bkinmanoh, awesome.
22:11.14bkinmanIll look into that.
22:12.09khembkinman: it will also speed up your build if you used =g instead of g3
22:12.57bkinmanWhere do i change that at?
22:13.35khembkinman: whats your DISTRO
22:14.03bkinmanI'm using  angstrom.
22:14.24khemok open conf/distro/include/angstrom-glibc.inc
22:14.39khemand you should see something like FULL_OPTIMIZATION = "-fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3"
22:15.00khemreplace -ggdb3 with -g
22:15.09Jay7-O2 -ggdb3?
22:15.19khemthats crazy but thats how it is
22:15.30Jay7hm.. looking strange :)
22:15.37khemuclibc was 232M when built with -ggdb3 :)
22:15.50khemangstrom maintainers like it
22:15.58Jay7omg
22:15.59khemas they are blessed with large harddisks
22:16.12Jay7well.. sleep anyway :)
22:16.21khemI stopped using angstrom for very same reason
22:16.24khemI use minimal
22:16.27khemits sleek
22:16.37khembkinman: did you get it ?
22:16.40Jay7-> sleep()
22:16.52bkinmani'm resizing my virtual disk partition, hehe.
22:17.45TartarusWell, -ggdb3 makes debugging deployed stuff easier i think
22:17.52Tartarusneeds to find the time to confirm this, one of these days
22:18.13khemTartarus: may be but at what cost
22:18.15Tartarusis busy kicking bitbake world -k -c fetchall actually finish, with strict checksums disables
22:18.32Tartaruskhem: I'm with the Angstrom folks, sorry
22:18.48TartarusNot that I advocate minimal/micro going -ggdb3 too
22:19.00Tartarusdisk is cheap, even laptop disk
22:19.01khemTartarus: I have found that -g is good for debugging
22:19.08khem-g3 is overkill
22:19.19Tartaruskhem: I think the point of -ggdb3 is that you don't need sources around then
22:19.23TartarusTHat's what I want to confirm anyhow
22:19.26khemunless you compress debug info
22:19.29khemwhich gcc does not
22:19.52khemTartarus: why you dont need sources ?
22:20.04khemhow would you do source level debugging without them
22:21.03Tartaruskhem: What I suspect and would like to confirm is that -ggdb3 gives you what you need when you don't want to debug libpcap (for example), but your libpcap using app and you're stepping in to see what's going on
22:21.20TartarusThat's when you don't care about having libpcap sources around
22:21.24Tartarusbut do want source level debug
22:22.01khemTartarus: I dont get you. Do you just want frame info and symbols ?
22:22.06khemfor those
22:22.17khemthey will be there with -g as well
22:22.38khemg3 adds macro debugging capabilities the biggest source of bloat
22:22.53khemand it will generate it for every occurance and use of the macro
22:22.54khemlame
22:23.24khemthere is a fine compromise you have to have with opt level and debug info
22:23.45khemif you are asking for O2 lot of that bloated crap is wrong anyway
22:24.04khemgcc emitted that just because you asked for it.
22:24.22khemIf you used something like -O0 -g3 then ok
22:24.30khemyou will get super duper debug info
22:24.41khemand world class debugging experience
22:24.51Tartaruskhem: Like I said, it's something I want to confirm before I speculate more
22:25.02Tartarusand I'm also assuming that there's a good and tested reason for it in Angstrom
22:25.14khemTartarus: I have used both so I am speaking from experience
22:25.35khemthere could be a good reason but I dont know that
22:25.45TartarusYes, that's what I'm speculating about
22:25.49khemgenerally we should approach it differently
22:26.16khemwe should have options sets which dont harm debugging that much
22:26.37khemand then another option set which doesnt care about debugging at all that would be need for speed kind
22:27.01Tartarusimho, anything that says "we build differently for debug vs not" is a deal breaker
22:27.15TartarusYou will then get the bug that shows up in the 'not' case
22:27.38khemI agree. However this is an option for daring ones
22:27.55khemwe might go conservatively with the option set thats good for debugging
22:28.19khembut we should also have an option to deteriorated debugging experience but faster speed
22:28.59khemthe current option set we use is crazy
22:29.29khemwe tend to optimize for size but then we ask for frename-registers and expensive-optimizations
22:29.35khemthats counter intuitive
22:35.56Tartaruser, wait, how so?
22:36.26TartarusIn that both of them are perf and necessarily size related?
22:36.29khemTartarus: let me try out something like -g3 -feliminate-dwarf2-dups -femit-struct-debug-baseonly -femit-struct-debug-reduced
22:36.55khemTartarus: no expensive-optimizations break debug info
22:37.33Tartaruskhem: Other than the usual debugging optmized code is hard?
22:37.37khemand same holds for rename-register
22:41.24*** join/#oe bitkiller (~bitkiller@187.112.56.177)
22:41.45khemTartarus: with gcc 4.5 debugging optimized code is much improved
22:41.54khemI just debugged uclibc last night :)
22:42.02khemit could tell me all about locals
22:42.16khemat anypoint in execution in a function
22:42.35khemI am all for ggdb3 but it should be managable
22:43.19TartarusI think you should make a case for Angstrom folks to change the flag once they're ready to switch to 4.5, and what to switch it to :)
22:43.27Tartarusand make it to them
22:43.40khemmy playground is minimal
22:43.41khematm
22:44.02khembut most of OE users use angstrom so yes you are right
22:44.24khemlet me experiment with minimal and come up with a good opt combo for debugging
22:44.45khemis sleep deprived
22:45.27ant__is following the debug saga
22:45.43khemTartarus: but 500K of uclibc code and 202M of debugging size for it is something to worry dont you agree
22:46.10ant__could once build in tmpfs with only 8GB ram
22:46.28khemant__: gone are days when people use gcc 2.95 :)
22:46.43ant__he..it was not so long ago
22:46.45khemnow gcc can shower so many bits on you if you ask for it
22:46.57ant__before git native expansion
22:47.30khemproblem with lot of debug info is that static linker  (ld) takes a lot longer to link apps
22:47.31ant__and before console-image pollution
22:47.42ant__with extra X packages
22:47.45khemwhich will prolong the build time even more
22:47.49ant__yes
22:47.51Tartaruskhem: I do not care about size, seriously
22:48.02khemTartarus: how about build time ?
22:48.20TartarusFor OE? hahah
22:48.25TartarusSeriously tho
22:48.28khemTartarus: try to debug such a uclibc system on say qemu or some other embedded board
22:48.32ant__khem: it is the same moving from core2 to core4 one year after :/
22:48.38khemgdb takes ages to load that uclibc debug info
22:49.12Tartaruskhem: On what vintage of a machine are you working tho?
22:49.13khemTartarus: everyone is not blessed with faster machines and lot of hd we should be considerate to them :)
22:49.32ant__already bricked 2 HDD building furiously
22:49.33khemTartarus: heh I have fairly good machine its a T61
22:49.38khembut my hd it 100G
22:49.45Tartarus'fairly good' ?
22:49.46khemand I can only have one angstrom image
22:50.15khemTartarus: well its a core2duo 2GHz
22:50.21khemwith 2G ram
22:50.30khemand 100G hd
22:50.39khemshould be enough in modern times
22:50.53khemwe are not paid by intel's and amd's to create killer apps :)
22:50.59Tartarusheh
22:51.27TartarusWell, that's why I care about the case of people debugging stuff where it wasn't built
22:51.39TartarusAnd what's really needed to make that happen, without OE around
22:52.04khemfair enough
22:52.15TartarusSince OE is a full system of the world, rather than an app development environment
22:52.24khemyes
22:52.41TartarusYour laptop should def. be enough to write and debug apps, but no, building a full system on there is a stretch
22:52.45*** join/#oe hillct_ (~hillct@cpe-174-109-201-200.nc.res.rr.com)
22:52.59khemTartarus: I dont agree :)
22:53.00TartarusHeck, my IT-approved developer laptop is a bit of a stretch at times
22:53.18khembecause then I dont have other machine to work on
22:53.20khemhehe
22:53.50Tartaruskhem: It's the difference between what resources you need to build a single big thing (even gcc/kernel/Eclipse/whatever) vs a full system of software
22:53.54Tartarusimho
22:54.01khemI am saying we should not generate stuff blindly just because we can.
22:54.05Tartarusand that's why I don't care so much about disk space or build time
22:54.12Tartaruskhem: I'll agree there too
22:54.17khemwe should weigh if it really makes sense to have that much of debug info in practice
22:54.31TartarusIf it adds value, it should be done, if not, not
22:54.36TartarusWe just disagree about what value is :)
22:54.48TartarusAnd really, you should argue with the angstrom folks to drop down from -ggdb3
22:54.54*** join/#oe woglinde (~woglinde@f052235155.adsl.alicedsl.de)
22:54.56TartarusOr switch to minimal/micro :)
22:55.33khemyes for me if I can have same level of debugging with -g and -g3 may be -g3 is a bit more but then it needs triple the size and increased build time and load time in gdb
22:55.48khemI would think -g is more valuable as practical solution
22:56.23khemI use to fight star craft with unlimited reasources :) but thats not reality
22:57.34khemmore than one OE user have complained about the problem bkinman ran into with angstrom
23:00.01Tartaruswrt this channel, that's an argument to make minimal or micro 'better' somehow
23:00.29khemyes
23:00.29Tartarusor slugos or whatever.  And 'better' might have been better said as more popular or visible or whatever
23:00.43khemI am going to experiment with improvised debug opts
23:01.10khemangstrom like OE is a brandname where as minimal/micro are not
23:01.28khemI am happy that mwester chose eglibc for slugos now
23:02.23ant__minimal is much more appealing than before now
23:03.01ant__I'd say is bleeding-edge wrt toolchain (thx khem :)
23:03.19ant__shr too
23:04.08*** join/#oe bitkiller (~bitkiller@187.112.157.82)
23:06.30ant__brb
23:08.45*** join/#oe ant__ (~andrea@host96-74-dynamic.5-87-r.retail.telecomitalia.it)
23:08.48*** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net)
23:09.02*** join/#oe mrc3_ (~mrc3@nat/ti/x-lucmgoaxydbvznuz)
23:09.18*** join/#oe robtow (~rob@12.156.66.34)
23:13.09*** join/#oe dth (~dieter@a89-182-129-143.net-htp.de)
23:21.37khemant__: thx
23:21.51khemant__: I am sad that italy exited the WC so early
23:22.01khemI was rooting for them
23:22.01ant__oh, *that* matter...
23:22.22khemboth winner and runner up of last wc out in first round
23:22.35ant__indeed
23:23.08khemmy bicycle has italian made components from bianci and scattante
23:23.22ant__big brands;)
23:23.25khemalthough made in taiwan :)
23:23.48khemant__: I like the parts though
23:23.53grgtdf starts this weekend. woot!
23:23.57khemmy bike runs like a billy goat
23:24.09khemyeah grg
23:24.11khemhello
23:24.16grgmorning
23:24.37khemgrg: opkg needs to do better :)
23:24.48grgkhem, of course :)
23:25.55khemgrg: which city are you in
23:26.04grgkhem, adelaide
23:26.41khemgrg: I was once authorized to visit linux.conf.au
23:26.52khembut could not make it as my daughter was to be born
23:27.10khemthat was my only chance to visit australia thus far :)
23:27.16grgi've not been to a linux.conf.au
23:28.33grgalways seem to be doing something else at that time of the year...
23:28.56grgHas any thought been given to randomising the bitbake queue in order to pick up missing build dependencies?
23:29.35mwesterwonders how that would help
23:30.30grgwell, lots of build deps are explicit in the recipe, they just happen to be built because of a rather obscure dependency chain
23:30.38grgs/are/aren't/
23:31.33grge.g. xserver-kdrive_1.5.3.bb appears to depend on openssl, which is not in its dependency list and it only fails now because i removed openssl as a dependency from my opkg recipe
23:32.12grgi don't know if xserver-kdrive depends on opkg, but it probably doesnt
23:33.01mwesterAh, ok, so randomizing would have the effect of uncovering these missing dependencies.
23:33.08khemgrg: hmm yeah there are several case where apps build because they find a dependency because someone else pulled it in for them
23:33.17grgyeah
23:33.30mwesterI would think if we had enough BB threads running, that would do the same, no?
23:33.48grgmwester, probably
23:33.58buZzi've just seen bitbake die from multiple BB threads
23:34.06mwestergoes to search for a 1000-core processor.
23:34.08grgit was just an idle thought....
23:34.14khemI guess we could have a mode in bb where it traps the open syscall and notes what file is being opened
23:34.30khemthat will be best way to track dependencies
23:34.46khemmay be a kernel module or something that talks to bb
23:34.57mwesterCustom filesystem
23:35.04mwestercould even be a user-space fs
23:35.09khemthis way we will find complete depchain
23:35.14mwesterJust has to report file operations
23:35.22mwesterand pass them to teh underlying fs
23:35.42mwestercommercial products exist that do that already.
23:35.45khemyeah something like that
23:35.49khemhmm cool
23:36.19khemI did not know that
23:36.27khemI am working on something similar
23:36.33khemfor my paid work :)
23:36.45mwesterIBM's ClearCase, and Electric Cloud's emake and electrify products
23:37.11khemah cool
23:37.16khememake sounds nice
23:37.39mwester(Disclaimer: I worked for the company that originally wrote ClearCase, and my current employer does emake/electrify)
23:37.52woglindegrg mweser rational?
23:37.56woglinde*g*
23:37.56mwesterAtria
23:38.06woglindehm
23:38.15mwesterI worked for Rational for a year after they aquired Atria
23:38.22woglindehm hehe
23:38.31mwesterThey were too big a company, no fun at all.
23:38.58woglindeI once had to work around clearcase not avaliable encrypted transport
23:39.23woglindeI used the email patch support and gpg
23:39.24Tartarusmwester: Put OE into emake before?
23:39.31Tartarusor just usesyou mean?
23:40.05mwesterTartarus: I tried, failed -- electrify is a better fit, but I'm on another project and have had absolutely no time to work on it.
23:40.26Tartarusk, thanks
23:40.35mwesterwoglinde: Clearcase was slow without encryption, i can just imagiine how painful that must have been!
23:41.16woglindemwester hm ah I remeber email was the only way we got internetconnection to the other company
23:41.36woglindewas around 2001
23:42.31mwesterTartarus: the issue is that emake would only distribute threads at the makefile level, i.e. do_configure, do_compile tasks.  I wanted to be able to distrbiute bb tasks out.  I think it can work, but it will be tough.  I need to convince my employer that it would be a great learning project and let me try it during working hours. :)
23:46.14Tartarusheh

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