IRC log for #oe on 20101209

00:01.10CroftonTartarus, I softlinked perl so it ran, which led to http://pastebin.com/NmWMNq7X
00:01.31TartarusSo it's still there,ok
00:01.37TartarusBut... why
00:02.42TartarusBut it really does all work if you undo 8da17586c547f365ae667eb2608ba89a1c375afc ?
00:05.53CroftonI am thinking about trying that ....
00:06.02Croftonit worked last month :)
00:07.55coreyfroCan anyone point me to THE AUTHORITATIVE GOSPEL  for building kernels for open embedded?  I need a complete sanity check here and the documentation I have found is fragmented at best.
00:08.01coreyfroI have built a KNOWN WORKING kernel image, I have extracted the config from that function kernel.  I want to make changes to the config but even if I just use the KNOWN WORKING config, my overo fails to boot.  However, when I copy the original kernel over, it boots just fine. I feel I have missed a step, but I have repeated the instructions I've followed repeatedly
00:09.46khemcoreyfro: this is not a paid support channel first of all. So writing in CAPS can throw off people
00:10.18grgcoreyfro, linux.inc will make some changes to your config. You could check that this is not removing/adding something that affects your kernel adversely
00:11.21kergoth_damnit
00:11.23kergoth_hmm
00:11.29coreyfroThanks GRG, I'll take a look
00:14.33coreyfroIs there a How To for building kernels alla OE? I've used http://www.openembedded.org/index.php/Kernel_Building but it's incomplete.
00:15.07coreyfroOr at least following those directions alone has not resulted in a built kernel
00:15.54khemdocumentation probably is a problem in OE so we always ask for sending doc fixes when someone like you go through the tribal rituals of OE
00:16.18khemare you using OE master or some offshoot
00:16.22Croftonif we had good documentation, no one would pay us for consutling
00:16.41coreyfrokhem: OE master
00:16.45Croftonhopes coreyfro has a sense of humour
00:16.59Croftoncoreyfro, did you find xoras blog entry on this
00:17.20coreyfroCrofton: I've worked for the feds, either I do, or I don't have feelings, so it doesn't matter
00:17.36khemcoreyfro: ok, usually machine maintainers should have added a working defoconfig to relevant kernel
00:17.38coreyfroNo, but I'm going to go look for it
00:17.54Crofton|workhttp://www.xora.org.uk/2009/12/10/openembeddedangstrom-kernel-workflow/
00:18.01Crofton|workhe's asleep now
00:18.04Crofton|workor drunk
00:18.06Crofton|workor both
00:18.34kergoth_sighs, just ran into a deadlock in bitbake using the separated ui branch + his changes when its limited to just one processor
00:18.41kergoth_grumbles
00:18.42Crofton|workheh
00:18.45Crofton|worktough stuff
00:19.06Crofton|workI hope to run the device driver I jsut "finished" on a multi core arm one day
00:19.14Crofton|workI suspect that will be very educational
00:19.16kergoth_thankfully there's very little shared state, and its mostly just a matter of ensuring that queues are emptied before shutting down a process and the like
00:19.34Crofton|workTartarus, do you want me to revert that changeset and see if things work
00:19.39kergoth_prefers mostly collaborative multitasking with explicit communications channels
00:19.43kergoth_messaging > shared
00:20.20khemneeds some article to read during the light rail ride
00:20.39khemcoreyfro: which kernel version is it building
00:21.40coreyfroOk, I found a defconfig for Beagleboard in recipes/linux/linux-omap-2.6.32
00:21.46khemlinux-omap_2.6.29.bb seems to have preference
00:22.27coreyfrounfortunetly, I need the thin wifi firmware for Overo, which means I need the later kernels
00:22.32khemcoreyfro: look in your build tree and see which version is it choosing
00:22.37coreyfroAnd I got it working, I just don't remember how
00:23.21coreyfroI built the kernel and configured it myself following http://www.openembedded.org/index.php/Kernel_Building
00:23.29Crofton|workkhem, your fix looks good
00:23.40khemCrofton|work: thank you
00:23.56coreyfroI don't believe it built a kernel, I've always built it alone
00:23.59khemI now need confirmation from ericben and effem for their fixes then I can commit all 3 in one
00:24.39kergoth_coreyfro: building any image or sdk will automatically build a kernel as a part of the build process, or you can just bitbake virtual/kernel.  nothing to it
00:24.58coreyfroYou know what, I think I prefixed MACHINE="beagleboard" before the bitbake command, does the MACHINE variable matter for this opperation?  Recently I was using OVERO
00:25.12khemheh
00:25.14kergoth_of course it does.  it has *EVERYTHING* to do with this
00:25.24kergoth_machine is what controls which kernel is built and what config is used for it
00:25.45coreyfrohah, but I am building for an overo
00:26.03Crofton|workkhem, no
00:26.03coreyfroand overo isn't working
00:26.05Crofton|workfailed again
00:26.13Crofton|workkhem, sorry I was premature
00:26.16coreyfrolemme see if that makes it work
00:26.27khemCrofton|work: ok now on your target
00:26.35Crofton|workok
00:26.37khemfind . -name "libgcc_s.so"
00:26.47Crofton|workdoh
00:26.49Crofton|workwait a minute
00:26.58Crofton|workwrong window
00:27.00Crofton|worksorry :)
00:27.01khemI mean find / -name "libgcc_s.so"
00:27.10Crofton|workI looked at the old failure :)
00:27.16Crofton|workit is still going
00:27.24Crofton|workneeds to take a break
00:27.29khemsee's crofton's wiggly eyes
00:27.42Crofton|workI just had it up to see where the failure was
00:27.43*** join/#oe Openfree` (~Openfreer@116.228.88.131)
00:27.53khemok so it worked or not ? final answer
00:27.54Crofton|workI am 99% certain the build is past it now
00:28.03Crofton|work99% certain fix is good
00:28.17khemok I will grab a tea and see if 1% is falling on me
00:28.24CIA-10103Chris Larson <chris_larson@mentor.com> 07master * rfc64eff03f 10bitbake.git/lib/bb/ (command.py cooker.py):
00:28.25CIA-101cooker: add shutdown/stop methods
00:28.25CIA-101Signed-off-by: Chris Larson <chris_larson@mentor.com>
00:28.26CIA-10103Chris Larson <chris_larson@mentor.com> 07master * rc7c8945ef7 10bitbake.git/lib/bb/ (command.py cooker.py):
00:28.26CIA-101cooker: merge cookerState and cookerAction
00:28.26CIA-101Signed-off-by: Chris Larson <chris_larson@mentor.com>
00:29.05coreyfroAre any of you in the SF bay area?  We have a new Embedded Linux group at Noisebridge
00:29.20coreyfroWe meet on thursdays
00:30.50CroftonI am there sometimes
00:30.58Croftonkhem works there
00:32.51Jay7-> sleep
00:39.18kergoth_oh son of a bitch
00:39.20kergoth_sighs
00:44.50kergoth_okay, this will work around it for now.. hrm
00:49.24kergoth_i really hate ^C.
00:51.16kergoth_argh
00:56.13khemcoreyfro: oh TinyTux thing
00:56.49khemcoreyfro: Allison mentioned it on our meetup for Silicon Valley Linux Technology group
00:57.14khemcoreyfro: I am in San Jose and hate the commute to city
00:57.39khemunless it was somewhere local it would be interesting
01:00.46*** join/#oe fraxinath (~quassel@p4FD65AA1.dip.t-dialin.net)
01:03.02coreyfrokhem, then you should check out hackdojo.  It's the baby of David Weekly of PBWIKI and Super Happy Dev House fame
01:03.20coreyfrokhem: So, the beagleboard kernel works on my overo
01:03.27khemcoreyfro: ok enjoy
01:03.28coreyfrobut not my overo kernel
01:03.42khemcoreyfro: I talk at SVLT few times thats all
01:03.57khemon various things related to embedded lnx
01:04.26kergoth_sighs at bitbake
01:04.43kergoth_can see the attraction of a rewrite :|
01:10.45Crofton|worknotes kergoth_ has said that for years
01:10.54kergoth_nods
01:11.00kergoth_still true
01:13.21kergoth_hard to work up the energy to take on something like that though, particularly since itd be a long time until it got to the point where it worked as well as the current bits
01:14.41khemkergoth_: rewrite is probably harder but refactoring can lead to rewrite over a  period of time
01:15.02kergoth_yeah, thats the goal, but its slow going, and frustrating at times
01:15.08khemI know
01:15.10khem:)
01:15.30khemI am starting a branch for recipes layers
01:15.32kergoth_the worst is the lack of unit tests.  refactoring without unit tests is MADNESS
01:15.37khemon lines with poky
01:16.05kergoth_looked at koen's angstrom repo? might want to build on that
01:16.08khemyeah unit test is must actually its never late it needs to be started at some point
01:16.46kergoth_its tough to add them when the components are so intertwined though :(
01:16.55kergoth_need to refactor to unit test to refactor
01:16.57kergoth_or something
01:17.01kergoth_:)
01:17.13khemkoen layed on top of poky isnt it
01:17.53kergoth_well, until the vote occurs, we don't know which direction we're going in, either way there's a risk that any work on layering will be wasted
01:18.03khemright
01:18.17khemwhat I am gonna try is create same structure within OE
01:18.26khemand use OE recipes
01:18.51khemwe can then easily plugin yocto into core or out of core
01:19.01kergoth_should probably focus on the bits that aren't already in yocto/poky then, eh?
01:19.02kergoth_hmm
01:19.02khemwhatever we decide
01:19.04kergoth_its a good idea
01:19.45khemwe can fine tune the layers later
01:19.54khemas we go
01:20.03kergoth_going to go category based, graphics, multimedia, etc?
01:20.08khemyes
01:20.09kergoth_i'd think itd be the best route
01:20.23kergoth_outside of the distro/machine layers, anyway
01:20.36khemyes
01:20.49khemthe machine/distro thing will be next
01:21.30khemI dont know if git will let me sync update into moved trees
01:21.35khemI mean dirs
01:22.04kergoth_you should be able to leverage filter-branch to rip out full history of files/dirs into a separate branch and put that in another repo later
01:22.05khemif not then one day we have to have a flag day
01:22.19kergoth_the problem is updating filter-branch'd branches from upstream
01:22.23kergoth_thats a nightmare
01:22.24kergoth_hmm
01:22.30kergoth_and just mv'ing is worse
01:22.33kergoth_due to conflicts
01:22.34kergoth_hmm
01:22.48khemyeah so prolly I have to work on master
01:22.55khemand seep in the changes
01:23.43kergoth_hmmm
01:24.02kergoth_git has a subtree merge, but thats for the reverse, putting another tree into a subdir, not taking a subdir of another tree
01:25.00khemI think if git could identify moved files it will be nice
01:25.14kergoth_it can, but i'm not sure how smart it is about merges with them
01:25.28khemyeah need to see
01:25.41khemlast time I tried something like that it did not go well
01:25.47khemI had to rename and commit
01:25.54khempush
01:26.27kergoth_i remember seeing lots of conflicts any time i tried stuff like that, but i think i saw the most problems with rm'ing and then merging changes to the rm'd files, moving might be less painful
01:26.32kergoth_thinks
01:31.59*** join/#oe dromede (~quassel@78-0-201-66.adsl.net.t-com.hr)
01:37.32*** join/#oe _julian_ (~quassel@hmbg-5f76172d.pool.mediaWays.net)
01:38.56*** join/#oe Openfree` (~Openfreer@116.228.88.131)
01:41.58*** join/#oe lostincake (~Aditya@pool-96-255-243-239.washdc.fios.verizon.net)
02:23.46fidencioJaMa|Zzz: hey you!
02:24.47*** join/#oe lostincake1 (~Aditya@pool-96-255-243-239.washdc.fios.verizon.net)
02:24.53*** part/#oe lostincake1 (~Aditya@pool-96-255-243-239.washdc.fios.verizon.net)
02:28.01*** join/#oe cbrake_ (~cbrake_@oh-69-34-21-229.sta.embarqhsd.net)
02:32.52*** join/#oe kergoth (~kergoth@ip24-251-170-95.ph.ph.cox.net)
02:58.00*** join/#oe vanous (~vanous@194.228.223.3)
03:01.16*** join/#oe fraxinas (~quassel@p4FD64AC4.dip.t-dialin.net)
03:06.39CIA-10103Khem Raj <raj.khem@gmail.com> 07master * r8805bb48b9 10openembedded.git/recipes/binutils/ (13 files in 2 dirs):
03:06.39CIA-101binutils-2.21: Add recipes for binutils 2.21 release
03:06.39CIA-101Signed-off-by: Khem Raj <raj.khem@gmail.com>
03:06.51CIA-10103Khem Raj <raj.khem@gmail.com> 07master * r6454b9669d 10openembedded.git/recipes/binutils/binutils_git.bb:
03:06.51CIA-101binutils_git.bb: Move to master now that 2.21 is released
03:06.52CIA-101Signed-off-by: Khem Raj <raj.khem@gmail.com>
03:07.57*** join/#oe jmpdelos (~polk@outgoing.delos.com)
03:08.49CIA-10103Joshua Lock <josh@linux.intel.com> 07master * r6c086dab25 10bitbake.git/lib/bb/cooker.py: (log message trimmed)
03:08.49CIA-101bitbake/cooker: fix idle command processing in servers
03:08.49CIA-101idle command processing in each of the servers does not handle an explicit
03:08.49CIA-101None return value, which means the goggle UI ends up repeatedly adding
03:08.49CIA-101"Tasks Summary:" rows to the list.
03:08.56CIA-10103Joshua Lock <josh@linux.intel.com> 07master * r38f59ad6db 10bitbake.git/lib/bb/ui/crumbs/runningbuild.py:
03:08.56CIA-101bitbake/crumbs: do the test for ignored messages sooner
03:08.56CIA-101Move the test for ignored messages to the start of the message handling loop to
03:08.56CIA-101avoid doing work for messages which are only going to be ignored.
03:08.56CIA-101Signed-off-by: Joshua Lock <josh@linux.intel.com>
03:09.07CIA-101bitbake/goggle: interaction tweaks
03:09.07CIA-101Set the goggle window to a more sane default size (640x480) and hook up the
03:09.07CIA-101close button.
03:09.07CIA-101Signed-off-by: Joshua Lock <josh@linux.intel.com>
03:09.07CIA-10103Joshua Lock <josh@linux.intel.com> 07master * rd2c4d0b2af 10bitbake.git/lib/bb/ui/crumbs/runningbuild.py:
03:09.14CIA-101Due to some recent change *somewhere* we need to explicitly look at the
03:09.14CIA-101name attribute on the instances class, rather than the name attribute of
03:10.01CIA-101the instance.
03:10.01CIA-101Signed-off-by: Joshua Lock <josh@linux.intel.com>
03:10.01CIA-10103Joshua Lock <josh@linux.intel.com> 07master * r0debaba644 10bitbake.git/lib/bb/server/xmlrpc.py: (log message trimmed)
03:10.01CIA-101bitbake/xmlrpc: Modify xmlrpc server to work with Python 2.7
03:10.02CIA-101Python 2.7's library changes some of xmlrpclib's internal implementation such
03:11.02CIA-101Signed-off-by: Joshua Lock <josh@linux.intel.com>
03:18.40*** join/#oe Lopi (~Lopi@173-9-230-97-Illinois.hfc.comcastbusiness.net)
03:48.04*** join/#oe rsalveti (~rsalveti@201.82.72.47)
03:51.21*** join/#oe nitink (~nitink@nat/intel/x-rocdbrwgpdpbzija)
03:52.41*** join/#oe mrj10 (~mrj10@63.252.64.254)
03:56.51*** join/#oe nitink (~nitink@nat/intel/x-roxncbmheeulhwao)
03:57.13*** join/#oe lostincake1 (~Aditya@pool-96-255-243-239.washdc.fios.verizon.net)
03:57.19*** part/#oe lostincake1 (~Aditya@pool-96-255-243-239.washdc.fios.verizon.net)
04:00.29*** join/#oe Jay7 (jay@95-29-187-121.broadband.corbina.ru)
04:03.37*** join/#oe kevinsc1 (~a0214685@nat/ti/x-nevrzrtsfjadmodc)
04:05.21*** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net)
04:25.13CIA-10103Richard Purdie <rpurdie@linux.intel.com> 07master * r6b6ae76ba5 10bitbake.git/lib/bb/data_smart.py:
04:25.13CIA-101bitbake/data_smart: Refactor _append/_prepend code to remove duplication
04:25.13CIA-101Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
04:25.19CIA-10103Richard Purdie <rpurdie@linux.intel.com> 07master * rba95240541 10bitbake.git/lib/bb/data_smart.py: (log message trimmed)
04:25.19CIA-101bitbake/data_smart: Fix append/prepend/override ordering issue
04:25.19CIA-101Where a variable name consisted of an append/prepend combined with an override
04:25.19CIA-101and there was also an append/prepend to the variable, the override could be lost
04:25.19CIA-101if the override was not in OVERRIDES.
04:34.48*** join/#oe tdebrouw` (~tdebrouw@91.182.122.167)
04:38.00*** join/#oe ksinkar (~ksinkar@static-mum-59.181.108.105.mtnl.net.in)
04:47.26*** join/#oe darkstar62 (~darkstar6@97-126-113-28.tukw.qwest.net)
05:21.56*** join/#oe thaytan (~jan@ppp59-167-167-201.static.internode.on.net)
05:26.27*** join/#oe vps (~vitus@hnvr-4d07bc40.pool.mediaWays.net)
05:33.57CIA-10103Chris Larson <chris_larson@mentor.com> 07master * r5670134ab2 10bitbake.git/lib/bb/taskdata.py:
05:33.58CIA-101cooker: use re match, not search in re_match_strings
05:33.58CIA-101We want to match the requested pattern at the beginning of the string,
05:33.58CIA-101otherwise things behave in an unintuitive manner wrt ASSUME_PROVIDED (e.g.
05:33.58CIA-101ASSUME_PROVIDED += "gtk+" will also assume foo-gtk+ is provided), and the user
05:34.08CIA-10103Chris Larson <chris_larson@mentor.com> 07master * re48e9a2150 10bitbake.git/lib/bb/taskdata.py:
05:34.08CIA-101taskdata: use 'any' in re_match_strings
05:34.08CIA-101Signed-off-by: Chris Larson <chris_larson@mentor.com>
05:43.12*** join/#oe vanous (~vanous@194.228.223.3)
06:05.09*** join/#oe hansdampf (~moritz@212.77.182.8)
06:06.33*** join/#oe lostincake1 (~Aditya@pool-96-255-243-239.washdc.fios.verizon.net)
06:07.38*** join/#oe lostincake (~Aditya@pool-96-255-243-239.washdc.fios.verizon.net)
06:10.35*** part/#oe lostincake (~Aditya@pool-96-255-243-239.washdc.fios.verizon.net)
06:29.25*** join/#oe dth_ntb (~dth@a89-182-143-184.net-htp.de)
06:34.54eFfeM_workgm
06:43.12JaMa|Zzzfidencio: hey! :)
06:48.20CIA-10103Khem Raj <raj.khem@gmail.com> 07master * r55b4c60e08 10openembedded.git/recipes/binutils/ (binutils-cross-sdk_2.21.bb binutils-cross_2.21.bb):
06:48.20CIA-101binutils-cross-sdk_2.21.bb,binutils-cross_2.21.bb: Use binutils_2.21.bb instead of git version
06:48.20CIA-101Signed-off-by: Khem Raj <raj.khem@gmail.com>
07:03.01*** join/#oe khem (~khem@99-57-141-118.lightspeed.sntcca.sbcglobal.net)
07:08.59*** join/#oe ksinkar (~ksinkar@static-mum-59.181.108.105.mtnl.net.in)
07:25.18*** join/#oe rob_w (bob@pD95EDCC8.dip.t-dialin.net)
07:26.33*** join/#oe Ironnads (~Ironnads@host109-152-199-112.range109-152.btcentralplus.com)
07:31.19ericbenhi khem
07:32.26ericbengood morning
07:34.14ka6soxkhem, patches looks good.
07:34.33*** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com)
07:36.00ericbenrelease 2010.12 is in today's LWM weekly letter, in the "Brief Items" section
07:37.16ericbenkhem: your patches to recipes/gcc/gcc-configure-sdk.inc gcc-package-cross.inc and gcc-package-target.inc fix the sdk problem, you have my ack for these
07:45.11*** join/#oe hansdampf (~moritz@212.77.183.229)
07:50.01*** join/#oe playya (~playya@unaffiliated/playya)
07:50.34*** join/#oe morphis_ (~morphis@brmn-4dbc85b4.pool.mediaWays.net)
08:03.04*** join/#oe risca (~risca@tappan-125-23.eduroam.liu.se)
08:07.23*** join/#oe zumbi (~zumbi@77.230.237.25)
08:08.53*** join/#oe mckoan (~marco@unaffiliated/mckoan)
08:09.22mckoangood morning
08:10.13*** join/#oe guufy (~Guufy@c-24-130-108-191.hsd1.ca.comcast.net)
08:11.40mckoanThis morning the server power supply has decided to infect the entire office with his stinks, a prelude to a fire :-D
08:13.04mckoanreplaced PSU before having to call the fire department
08:15.01*** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de)
08:18.46*** join/#oe Proxyles (~henrik@c-0890e255.56-4-64736c14.cust.bredbandsbolaget.se)
08:20.22ka6soxmckoan, good plan(tm)
08:21.13*** join/#oe playya (~playya@unaffiliated/playya)
08:22.59*** join/#oe roza (~ron@nat/cisco/x-jphvditccpuxtxvi)
08:23.00*** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net)
08:28.37*** join/#oe ensc (~irc-ensc@fedora/ensc)
08:29.49*** join/#oe risca (~risca@tappan-125-23.eduroam.liu.se)
08:48.35*** join/#oe lrg (~lrg@slimlogic.co.uk)
08:50.15*** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net)
09:05.49*** join/#oe dth_ntb (~dth@a89-182-198-2.net-htp.de)
09:21.57*** join/#oe NightMonkey (debian-tor@pdpc/supporter/professional/nightmonkey)
09:26.58*** join/#oe nani_ (7aa74eac@gateway/web/freenode/ip.122.167.78.172)
09:28.45*** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net)
09:36.52*** join/#oe atiti (~atiti@nbbd.imm.dtu.dk)
09:38.12*** join/#oe anarsoul (~anarsoul@86.57.155.118)
09:40.03*** join/#oe bluelightning (~paul@158.43.2.102)
09:40.03*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
09:50.59JaMasomeone with issues booting kernel when u-boot was built with gcc-4.5? same u-boot built with older toolchain works ok. I have it on armv7a (nokia900)
09:53.06*** join/#oe florian_kc (~fuchs@port-217-146-132-69.static.qsc.de)
09:53.07*** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian)
10:07.45mckoanJaMa: may happen, but I'm not sure
10:15.26JaMamckoan: it's hanging forever after showing
10:15.32JaMa"Starting kernel" here
10:15.53mckoanJaMa: so may be the kernel and not uboot
10:17.39JaMasame kernel binary for both u-boots
10:18.13JaMaalso current toolchain makes it 10kB smaller..
10:19.35mckoanJaMa: no clue, sorry
10:34.27*** join/#oe cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net)
10:41.57*** join/#oe ksinkar_ (~ksinkar@static-mum-59.181.108.105.mtnl.net.in)
10:44.25*** join/#oe dreadrasta (907aa7c7@gateway/web/freenode/ip.144.122.167.199)
10:44.36dreadrastahi everyone
10:44.57dreadrastai just build environment oe
10:45.07dreadrastai have a question
10:45.33dreadrastai use linux- ubuntu on ARM
10:45.50dreadrastathere is any distro for it
10:45.57dreadrastain oe
10:46.01dreadrastarecipes
10:46.52*** join/#oe likewise (~likewise@205-89-ftth.onsneteindhoven.nl)
10:48.39likewisegm
10:56.14*** join/#oe Jay7 (jay@95-29-187-136.broadband.corbina.ru)
10:56.17*** join/#oe dromede (~quassel@78-0-201-66.adsl.net.t-com.hr)
10:56.47*** join/#oe rob_w (~bob@217.237.177.190)
10:57.06*** join/#oe vanous (~vanous@robe.ludik.cz)
11:00.19*** join/#oe B_Lizzard (~havoc@athedsl-432928.home.otenet.gr)
11:04.58*** join/#oe ldnunes (~ldnunes@189.114.111.55)
11:18.19*** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho)
11:22.53*** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz)
11:23.16*** join/#oe GarthPS (~quassel@93.29.49.31)
11:44.59*** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho)
11:46.19*** join/#oe rsalveti (~rsalveti@201.82.72.47)
11:46.25tasslehoffis the release-tag final now?
11:51.11*** join/#oe dromede (~quassel@93-136-69-203.adsl.net.t-com.hr)
11:52.02*** join/#oe CMoH-office (~cipi@unaffiliated/c-moh)
11:56.02likewisetasslehoff: I think yes
11:56.14likewisetasslehoff: maybe a stable branch will follow on that release
11:56.37likewisetasslehoff: good question though, I will address it
11:57.27tasslehofflikewise: cool. we're planning a release in march, and I'm pondering if I should follow dev or stay stable :)
11:58.34CIA-10103Daniele Ricci <daniele.athome@gmail.com> 07master * r61cf049e1d 10openembedded.git/recipes/freesmartphone/libfreesmartphone-glib_git.bb:
11:58.34CIA-101libfreesmartphone-glib: bump SRCREV and version, now depends on fso-specs
11:58.34CIA-101Signed-off-by: Daniele Ricci <daniele.athome@gmail.com>
11:58.34CIA-101Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
11:58.41tasslehoffI see there's a branch at the same point as the tag now.
11:58.46CIA-10103Martin Jansa <Martin.Jansa@gmail.com> 07master * r84ab2a190e 10openembedded.git/recipes/freesmartphone/ (fso-specs_git.bb libfso-glib_git.bb):
11:58.46CIA-101fso-specs,libfso-glib: bump SRCREV and PV
11:58.46CIA-101Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
11:59.35JaMatasslehoff: tag it's finall, branch will be probably removed later
12:01.41likewiseJaMa: my proposal: can we rename or fork the branch so that we can do 2010.12.1 ?
12:02.12likewisei.e. so that 2010.12 is the first release, and also the branch root for stable bug fixes only.
12:03.35JaMaI wasn't on OEDEM but ie koen on ML said "At OEDEM we decided that the release would be a tag, not branch of .dev."
12:03.58JaMaI guess nobody volunteered to maintain such branch
12:04.45likewiseJaMa: it was decided that the actual users maintain it
12:04.56likewisejama: so not pre-assigned people
12:04.59JaMayes that's why SHR has shr/testing2011.1
12:05.09JaMawhich is based on this tag
12:07.09tasslehoffThanks for clarifying.
12:16.32Crofton|workjama the problem is branch users have many different ideas what maintenance policies should be
12:18.31*** join/#oe vanous (~vanous@robe.ludik.cz)
12:19.11likewiseCrofton|work: I'm not sure if that's true. We never spoke with any.
12:19.39likewiseCrofton|work: that issue was mainly brought up by the maintainer police.
12:19.50Crofton|worknotes constant low level chatter about the stable branch from people who do not like ho w it is maintained
12:21.58likewiseCrofton|work: that's  because currently the people who chatter are not maintaining it
12:22.14likewiseCrofton|work: I think we should simply put the users in command
12:23.06Crofton|workexactly
12:27.35*** join/#oe dth_ntb (~dth@a89-182-198-2.net-htp.de)
12:28.05*** join/#oe tws (~Miranda@mm-59-215-84-93.dynamic.pppoe.mgts.by)
12:36.49*** join/#oe valhalla (~valhalla@81-174-22-79.dynamic.ngi.it)
12:40.39*** join/#oe risca (~risca@tappan-125-23.eduroam.liu.se)
12:48.08*** join/#oe svolpe (~Gerrath@unaffiliated/gerrath)
12:52.57*** part/#oe cbrake_ (~cbrake_@oh-69-34-21-229.sta.embarqhsd.net)
12:56.57*** join/#oe rsalveti (~rsalveti@201.82.72.47)
12:57.25*** join/#oe grund (~grund@64.244.156.164)
12:57.37*** join/#oe stefan_schmidt (~stefan@2001:638:602:1183:21f:16ff:fe0d:7d41)
12:57.44*** join/#oe xeon-enouf (~xeon-enou@unaffiliated/xeon-enouf)
14:03.21*** join/#oe ibot (~ibot@rikers.org)
14:03.21*** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Bugtracker: http://bugs.openembedded.org and http://tinderbox.openembedded.org for compile issues | Repository: git.openembedded.org/openembedded and repo.or.cz/r/openembedded.git as ro mirror | This is not a distro or machine support channel
14:03.28foerster| cp: cannot stat `/home/foerster/dev/openembedded/dev/build/tmp/work/x86_64-linux/autoconf-native-2.65-r10.0/autoconf-2.65/autoconf-2.65.tar.bz2': No such file or directory
14:04.39kergothalso strange.  best clean first -- it shouldn't behave any differently from a build perspective under taskset or not under taskset
14:05.19foerstercleaning, will try again
14:06.38foersterstill fails, weird
14:07.40foersterBear in mind that a process that has put items in a queue will wait before terminating until all the buffered items are fed by the “feeder” thread to the underlying pipe. (The child process can call the Queue.cancel_join_thread() method of the queue to avoid this behaviour.)
14:07.47foersterfrom py docs
14:08.00kergothright
14:08.45kergoththats why i was thinking that might be the problem.  i tried emptying the queue from the ui before it exits, but then again you have the server and ui racing, if the ui empties any remaining items before the server stops adding items..
14:08.51kergothshrugs
14:08.59kergothoddly fun to work on this sort of problem
14:09.00foersterhm.  
14:09.10foersterright, though also annoying ;)
14:09.19kergothindeed
14:10.15kergothwhat i was going to do was have the ui tell the server stop, then after that empty the queue, and have the server wait for the queue to be empty before it exits
14:10.21foerster"Remember also that non-daemonic processes will be automatically be joined."
14:10.23kergothbut then i hit the .stop/.clear hang
14:10.36foersterthey say just to remove the join
14:10.48Crofton|workhmm
14:11.03Crofton|workHow do you control the order files are packaged in
14:11.12kergothhmmm, so the server won't be joined until the UI process exits, still might have an issue though
14:11.17kergothi'll test that, since i can reproduce
14:11.24Crofton|workI have some going into ${PN} but I want them in ${PN}-examples
14:11.36kergothCrofton|work: add ${PN}-examples to PACKAGES before ${PN}
14:11.39kergothuse =+ instead of +=
14:11.49Crofton|workok
14:11.54Crofton|workI was thinking that
14:12.06Crofton|workthe meaning is a ltittle funny
14:12.14Crofton|worksince you would think "subtract"
14:13.12kergoththink of +=/=+ as more like list operations on a space separated list.
14:13.18kergoth-= would remove an element from that list
14:13.51Crofton|workurh
14:13.53Crofton|workI saw -
14:14.23Crofton|workthat is cleare
14:14.29Crofton|workneed to get my contacts in
14:15.39*** join/#oe Openfree (~df@61.170.206.43)
14:18.02*** join/#oe playya_ (~playya@unaffiliated/playya)
14:20.51foersterkergoth_: we could try using a "Manager" - it says those queues aren't prone to such deadlocks
14:21.35kergothfoerster: huh, worth trying anyway
14:22.13foersteror, what if we have the server use cancel_join_thread()?
14:37.47pb__hi kergoth
14:38.22kergoth_hey pb__
14:42.47foersterkergoth_: updated cache progress events https://github.com/foerster/bitbake/commit/ff086b864b60cf76e5c48cda4d42d59a0b027ccd
14:43.00*** join/#oe jmpdelos (~polk@outgoing.delos.com)
14:43.01foersterseems to shave off most of the previous overhead
14:44.26*** join/#oe GarthPS (~quassel@93.29.49.31)
14:45.37kergoth_foerster: ah, nicely done
14:45.50kergoth_tests cancel_join_thread
14:46.34foersterkergoth_: also, try putting a timeout in the join, and then inspecting the queue
14:46.44foerstermaybe that will provide some insight
14:47.48foerstercould call join in a loop with timeout to test
14:48.45CIA-10103Michael Smith <msmith@cbnco.com> 07master * r8e91420560 10openembedded.git/recipes/iproute2/ (3 files in 2 dirs):
14:48.45CIA-101iproute2: upgrade to 2.6.35.1
14:48.45CIA-101Upgrade 2.6.35 to 2.6.35.1. The new version fixes "ip route get" and
14:48.45CIA-101"ip addr flush".
14:48.45CIA-101Signed-off-by: Michael Smith <msmith@cbnco.com>
14:50.29kergoth_canceling the join of the event queue thread fixes it
14:50.39kergoth_so we at least know for certain that that was the cause
14:51.02foerstersweet. Does not joining the queue thread cause any problems?
14:51.08kergoth_no idea :)
14:51.13foersterhah
14:51.20kergoth_i guess what it was trying to feed will never make it to the UI
14:51.27foersterwell, only problem of concern is -- is it still running?
14:51.34foersterthat thread get's wiped out still, I assume
14:51.41kergoth_my pthreads-fu is weak
14:51.43kergoth_i'd assume so
14:52.07kergoth_so i'd guess the UI just never gets those remaining events, but its likely the UI is on its way out anyway, since our UIs dont clear out the queue when they're exiting
14:52.18foersterright
14:52.35foersteralternatively, we could do the join loop with queue emptying
14:52.43foersterdon't know if that would have any benefit or not
14:52.48kergoth_yeah, don't know
14:53.01kergoth_this is the thing that bugs me about multiprocessing.  okay, it has all these classes that look nifty and all
14:53.07kergoth_but there's a crapload of ways to do things
14:53.18kergoth_where's the guidelines to tell me when to use which? :)
14:53.19foersterand not many good examples
14:53.21kergoth_yeah
14:53.53foersterwhen it works though, it does make things quite nice
14:53.59kergoth_personally, i'd rather stick to queues than proxies, it seems like using proxies just encourages thinkiing about the problem in the wrong way
14:54.24kergoth_managers do look somewhat interesting in general though
14:54.38foersteryes, but if we only use the manager to provide a safe queue, it'd be different.
14:54.50foersterplus, the manager can be long lived, and clients could later connect to it
14:54.54foersterand use the same queues
14:55.05kergoth_right
14:55.08foersterthere's some api in there for connecting to the manager i believe
14:55.25foersterbut, that's more of a drift from where we are now.  cross such bridges if/when necessary
14:55.31kergoth_right
14:56.06foersterdid you have a chance to play with my ^C handling, or should I bring in the way you did it?
14:56.19foerstermine was dead simple, but seemed to work
14:56.43foersteri saw you also found a way to join the cache sync thread, right?
14:57.47kergoth_i'm experimenting with your new branch + 2 small changes, one for the sync join yeah, the other is a slight change to the shutdown
14:58.46*** join/#oe hrw (~hrw@89-73-120-20.dynamic.chello.pl)
14:59.39kergoth_I did hit one issue with the current way of doing things.  if you actually bitbake something instead of doing -p, and ^C the parsing, it will continue to try to build -- returning False rather than raising an exception appears to be a problem, because none of the people that *run* updateCache (as opposed to the command that runs it for -p) check for successful parsing completion
14:59.59kergoth_so i think we may want to keep the sys.exit()s for the incomplete parses, or revamp those
15:00.06kergoth_or add a new exception
15:00.08foersterah, ok
15:00.32kergoth_but, i'm still looking into it
15:00.38kergoth_might be missing a cleaner method
15:01.13kergoth_hrm
15:01.45kergoth_although, all the buildTargets() does is registers the idle command after switching into the parsing state, it should still know to exit the idle function when the cooker enters the shutdown state
15:02.04kergoth_but maybe we have a race, its possible the state is being overwritten with a new value after its set to shutdown, perhaps
15:02.20kergoth_since the state machine doesn't do an explicit A->B transition to check sanity or anything
15:02.26kergoth_re-reads the code in question
15:06.00foersteryea, right now, it's crapping all over the floor if i ^c twice during parsing, when actually trying to build something
15:06.45*** join/#oe mrj10 (~mrj10@mjlap.crhc.uiuc.edu)
15:07.44foerster<PROTECTED>
15:07.44foerster<PROTECTED>
15:07.45foerster<PROTECTED>
15:07.45foerster<PROTECTED>
15:07.45foerster<PROTECTED>
15:08.05kergoth_ouch
15:08.17foerstersome funny business happening - we probably do need a better way to abort parsing
15:09.27kergoth_yeah.. before buildTargets registers its idle function, it creates the runqueue and crap all based on our incomplete parse
15:09.30kergoth_not good
15:10.04foerstersys.exit on any unclean parse shutdown?
15:10.05*** join/#oe mickey|office (~Mickey@openmoko/coreteam/mickey)
15:11.04kergoth_that's what i have it doing for now, but ideally the cooker should be able to shut itself down cleanly rather than raising SystemExit :) something to revisit in the future
15:14.08*** join/#oe grund (~grund@host65-17-84-58.birch.net)
15:14.19*** join/#oe dijenerate (~dijenerat@69.73.215.31)
15:16.48*** join/#oe vanous (~vanous@194.228.223.3)
15:19.22RPkergoth: I like the idea of runqueue and crap :)
15:19.36RPkergoth: care to join the tsc channel for a second?
15:19.52foersterthe ui probably needs to check for queue errors now so it can detect when the server exits, no?
15:21.36kergoth_chuckles
15:22.28kergoth_foerster: no, the systemexit gets caught by the code that's handling teh command, and raises CookerCommandFailed in the finishAsyncCommand or whatever
15:22.58foersterkergoth_: awesome, even better.
15:23.43*** part/#oe mrj10 (~mrj10@mjlap.crhc.uiuc.edu)
15:29.26Crofton|workI think I am having the issue where cleaning a task does not really clean it
15:29.30Crofton|workdoes that ruing a bell?
15:32.59kergoth_foerster: https://github.com/kergoth/bitbake/commits/separate-ui-and-server has my current changes on top of yours -- will still need to rebase on master again later, and perhaps rebase -i to merge some of the commits to clean up the history (well, we don't have to, but we'll probably want to, but can wait until just before we merge)
15:34.29kergoth_of course, the danger with using multiprocessing's finalizers is i don't know how portable they are across python versions :)  will have to verify 2.7 is happy
15:35.11kergoth_but i think its slightly cleaner than the finalize() bits
15:36.24foerstercool.  I'll bring your changes in.
15:37.09kergoth_should make better use of a TODO, either in a separate file, the readme, or on github or oe's wiki, or something
15:42.18*** join/#oe ensc (~irc-ensc@fedora/ensc)
15:42.48*** join/#oe jconnolly (~jconnolly@firebug.buglabs.net)
15:43.08foersterkergoth_: did you see the little bit in bin/bitbake blocking ^C?  I don't like it, b/c it could cause problems if the server for some reason hangs
15:43.33foersterbut not sure what else to do - it helps get rid of some ^C stack traces when the user tries to abuse us
15:43.35kergoth_thats not theoretical
15:43.43kergoth_i kept having to kill bitbake debugging this issue ;)
15:43.50foersterright
15:44.16foersteri thought maybe to block it, then join with a few second timeout or something
15:44.42kergoth_what's the danger if that bit isn't there?
15:44.55kergoth_should we just catch keyboardinterrupt and forcibly terminate the server if we have to?
15:44.55foersterjust extra uncaught ^c exceptions
15:44.59kergoth_nods
15:45.23foersterthat would probably work too
15:47.17kergoth_i guess the higher up you are when you catch keyboard interrupt, the better
15:47.32foersterwithout catching, you'd get a stack track showing server.join
15:47.32foersterother than that, everything is looking good here so far
15:47.43foersterwait, that's odd.  I'm always getting ERROR: Command execution failed: Exited with 1                                                                                                            | ETA:  --:--:--
15:47.49kergoth_hmmm
15:47.54kergoth_strange
15:48.01foerstercache loads, parsing doesn't happen
15:48.02foersterwtf
15:48.28kergoth_bisect my changes? :)
15:48.34foersterany attempt at parsing and it bails
15:48.41foersteryea, let me try
15:49.54kergoth_http://dustin.github.com/2010/03/28/git-test-sequence.html is interesting, from the useful git tidbits department -- could use it to make sure the individual commits in a branch don't cause breakage, at any point, so as to avoid breaking other people's bisects with unrelated problems, before merging it
15:51.53foersterhmm.  resurrect sys.exit usage causes me breakage
15:52.46foerstercommit ebdf3db3b612c1d56c8a71adb8bdffb327ca9582
15:53.21kergoth_hmm, well, maybe we should revisit the interrupted parsing for a build issue then
15:53.44foersterit's not even getting into parsing here
15:53.50foersterno interrupts at all
15:53.51foerster:)
15:54.27kergoth_what i mean is, drop that commit for now and revisit the issue it fixed later, since it clearly causes other problems
15:55.52foerstercurious what the hell it's doing though
15:57.13kergoth_agreed
15:57.22foersterit's bailing in updateCache
15:57.29kergoth_considering those should only be hit when shutting down
15:57.34foersterwhy is state shutdown or stop there when parsing?
15:57.35foersterright
15:57.36kergoth_i don't see how it could happen in a normal run
15:57.37kergoth_right
15:58.03khemericben|away: thanks
15:58.24khemeFfeM_work: did the gcc patch I gave helped your case ?
15:58.27khemgm all
15:59.29foersterkergoth_: should have been cookerAction, not cookerState I believe
15:59.35foersterstate is (clean, parsing, parsed)
15:59.41*** join/#oe dth_ntb (~dth@a89-183-4-63.net-htp.de)
16:00.05kergoth_oh, yes, that's my fault
16:00.08kergoth_master merged the two :)
16:00.11foersterah
16:00.14kergoth_maybe we should get that rebase done :)
16:00.15*** part/#oe dth_ntb (~dth@a89-183-4-63.net-htp.de)
16:00.40foersterprobably wise
16:00.49khemhttp://lwn.net/Distributions/#embed
16:00.54kergoth_its just state - initial, parsing, running, shutdown, stop now
16:00.59kergoth_which i think is much less confusing
16:01.00khemsearch for 'OpenEmbedded'
16:01.08foersterkergoth_: agreed
16:01.14khemrelease is mentioned
16:01.23kergoth_khem: nice
16:01.44khemI pinged Jonathan to add it
16:02.41ericbenhi khem
16:03.38khemhi
16:03.47ericbenwhile looking at the sdk problem, I found that when installing the sdk -tar -C / -xjf meta-toolchain.... we change the rights of /usr and /usr/local to 775 !
16:04.15khemhmm
16:04.16ericbenwhich is not a good thing ...
16:04.27khemright
16:04.56ericbenI have a patch for this : I do a chmod -R go-w before doing thez fakeroot tar in meta-toolchain.bb
16:05.03ericbenis that an acceptable fix ?
16:08.09khemericben: sounds ok to me. Send to ml
16:08.46khemI think we should update news section more often with OE dev news
16:08.55khemhowever small it is
16:09.25ericbenkhem: if you have access to the homepage of the wiki: is it possible to add http://wiki.openembedded.org/index.php/Presentations somewhere : this can be interesting for peoples to have an easy access to this
16:11.30khemI dont
16:12.23ericbenconcerning local generation with qemu : it seems qemu 0.13 hangs for ever when building into a virtualmachine run by virtualbox
16:12.38ericbenswitching back to 0.12.5 works
16:13.23JaMafor me (no virtualbox) it seems to build much longer, but it finishes ok in the end
16:13.25ericbenkhem: are you aware of big changes in qemu's configuration or code which could explain this ?
16:13.37ericbenJaMa: I did wait about 6 hours !
16:14.00foersterkergoth_: rebased onto master
16:14.39foersterhttps://github.com/foerster/bitbake/commits/separate-ui-and-server
16:14.41khemericben: hmmm, I just saw that it fixed a crash
16:15.22khemericben: I think I will add the cross locale generation to eglibc
16:15.26ericbenkhem: I can reproduce this 100% case until now (on different host either linux or windows as the native os)
16:15.36khemand get rid of qemu
16:16.01khemericben: ok reinstate 0.12.5 if you like
16:16.40JaMaericben: here it's about 50min, while normally (qemu-kvm in gentoo box) it's in about 10min
16:17.22JaMaericben: but for gentoo I'm not building all targets..
16:24.46kergoth_foerster: i really wonder why multiprocessing doesn't run atexit functions when shutting down, seems very strange to me.  in addition, it registers its exit functions with atexit, and also runs them explicitly in its Process
16:24.50kergoth_quite strange
16:24.55kergoth_might have to try to get ahold of the upstream
16:25.06kergoth_hmm
16:25.54*** part/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net)
16:27.24*** join/#oe aloisiojr (~aloisio@186.212.103.21)
16:30.36foersterkergoth_: yea, seems odd
16:30.37fidencioJaMa: Hey!
16:31.05fidencioJaMa: we have a serious problem with hours hehehe
16:31.41JaMafidencio: hey
16:31.53kergoth_hmm
16:32.26fidencioJaMa: a question. How you compile EFL with debug support? Are you using task-efl-x11-core (or something like this
16:32.29fidencio)?
16:32.34foersterkergoth_: http://mail.python.org/pipermail/python-list/2009-March/1196649.html  we're not the only ones confused
16:32.54kergoth_huh, indeed
16:33.04kergoth_tries a minimal test case
16:33.40JaMafidencio: without debug
16:33.59fidencioJaMa: 'cause I'm creating an image using e-wm*, but I can't found when eina,evas,edje ... are compiled. So, I can't add debug :-(
16:34.31fidencioJaMa: and EFL are segfaulting here. I think that is a stupid problem with efreet and freescale hardware
16:34.41JaMafidencio: and task-x11-illume
16:35.52JaMafidencio: #DEBUG_BUILD = "1"
16:35.53JaMa#PACKAGE_STRIP = "no"
16:36.09JaMato your local.conf (without #) and bump EFL_SRCREV to force rebuild :)
16:36.22kergoth_yeah, minimal test case shows the same behavior.  atexit registered in the main process gets run when it exits fine, but not the one in the Process
16:36.25kergoth_shakes head
16:36.35fidencioJaMa: Yeap. I do it.
16:36.53foerstersurely, there must be some reason :)
16:36.57fidencioBut I need to create my image with *-dbg packages
16:36.58kergoth_so, anyone know if git submodule stopped sucking?
16:37.05kergoth_or if its best to use alternatives like braid?
16:37.10kergoth_or mr, or..
16:37.16fidencioJaMa: the packages were created
16:37.19JaMafidencio: -dbg packages are built by default
16:37.33JaMafidencio: you can opkg install those on target
16:37.37kergoth_fidencio: IMAGE_FEATURES += "dbg" will add all -dbg packages to any image you build
16:38.00JaMaalso with ~200MB eglibc-dbg :/
16:38.05kergoth_hehe
16:38.12kergoth_maybe it needs a blacklist :)
16:38.13fidenciokergoth_: but it fails because there's packages that -dbg were not createad
16:38.15JaMakhem: any idea why is eglibc-dbg so big nowadays?
16:38.21kergoth_fidencio: then those packages should get fixed :)
16:38.33JaMakhem: or can we split eglibc-dbg ie to eglibc-static-dbg?
16:38.41fidenciokergoth_: nhaaaaaaam. hehehee. ok. I'll try again and will send patches
16:38.44kergoth_hehe
16:39.02kergoth_as JaMa said, can always install them manually, but might be faster to fix the recipes with no -dbgs :)
16:40.16fidenciokergoth_: bitch. I was looking for a lazy way. heheeh
16:40.34JaMafidencio: iirc you work for profusion, right? do you work on webkit-efl too?
16:41.22fidencioJaMa: nops. But antognolli, k-s, jprvita, demarchi and acidx (@ #edevelop) can help you :-)
16:43.21JaMaok thanks
16:44.55fidencioJaMa: you're welcome!
16:45.14kergoth_it's amazing how much time oe/bitbake can suck up.  i wonder if i'd have the *time* to add another project.  hrmph
16:45.34fidenciokergoth_: /me too
16:45.38fidenciobbl
16:46.41*** join/#oe CMoH (~cipi@unaffiliated/c-moh)
16:47.52*** join/#oe CMoH-notebook (~cipi@95.76.74.1)
16:47.52*** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh)
16:48.18*** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net)
16:48.33kergoth_hmm, my u-boot-fu is rusty, i should look for a guide for getting something useful on my sheevaplug
16:49.16JaMakergoth_: which gcc version are you using for u-boot builds?
16:49.27kergoth_none yet :)
16:50.03JaMakergoth_: I'm just building 4.3 to check if 4.5 is cause for my boot problems (when I build u-boot with 4.2.1 it works ok)
16:50.09kergoth_ah
16:50.12kergoth_interesting
16:50.52JaMaso better to practise your -fu somewhere safe :)
16:51.08foersteri did all kinds of crap in u-boot in the past, like making sure the production guys entered in a mac address before the system would boot, etc.  
16:51.29kergoth_hmm, i wonder if itd be possible to arrange filters on the oe list to only show me specific subsets of patches.  itd be really nice to only see the ones that touch the recipes you maintain, etc
16:51.43kergoth_or, maybe could do something with patchwork for that and archive all patches in gmail :)
16:52.00kergoth_notices he has to mute a *lot* of patch threads in the oe ml for things he doesn't care about
16:52.57JaMais just deletes the patches and threads which doesn't touch anything I ever use and keeping whole history only in gmail folder
16:53.26kergoth_i guess auto-archiving all patch threads to mailing lists could make sense, with a saved search to look at them explicitly
16:53.41kergoth_since i use my inbox as things that require action, 90% of the patches don't, so..
16:53.42kergoth_hmm
16:57.09*** join/#oe hansdampf (~moritz@212.77.183.229)
17:00.08*** join/#oe kevinsc (~a0214685@nat/ti/x-kxylvamnxyuvbbmo)
17:23.11pb_kergoth: yah, that sounds like an area where patchwork might be useful.  
17:23.22pb_can't think of any way to do it with straightforward MUA filters.
17:28.40CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * rddd56fb6cb 10openembedded.git/recipes/linux/linux-omap-hah_2.6.31.bb:
17:28.40CIA-101linux-omap-hah: remove unused variable CVS_TARBALL_STASH
17:28.40CIA-101Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
17:28.40CIA-101Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
17:30.16kergoth_yeah, really need to be able to inspect the patches themselves, run lsdiff from patchutils, whatever
17:30.40pb_right
17:31.04pb_I guess you could do it in a plugin, given a suitable mua, but something like patchwork is probably a more generally useful place for it
17:31.19kergoth_nods
17:31.24kergoth_i don't exactly use procmail anymore ;)
17:31.36pb_heh
17:31.55kergoth_i think my work mail server might support sieve, but i don't think it has the very useful plugins for it
17:31.59kergoth_ah well
17:39.29*** join/#oe woglinde (~heinold@f052064024.adsl.alicedsl.de)
17:41.06cbrakeunpacks panda board
17:41.10kergoth_nice
17:42.22woglindehi kergoth and cbrake
17:42.30fidenciocbrake: I'll get mine in the next week :-)
17:43.44kergoth_hey woglinde
17:44.51cbrakewoglinde: hello
17:46.37kergoth_foerster: separated ui/server seems reliably faster than unseparated for me in this test, testing with one cpu with taskset, autoconf-native.  getting times of ~236 seconds unseparated, 208-220 seconds separated -- :)  still testing though
17:47.03foerstersweet
17:47.19foerstergotta jet, dentist appointment. see ya for now
17:47.21kergoth_considering xmlrpc used to be *slower*..
17:47.23kergoth_later
17:48.54*** join/#oe anarsoul (~anarsoul@80.249.93.184)
17:51.22*** join/#oe morphis_ (~morphis@brmn-4dbc85b4.pool.mediaWays.net)
17:57.42*** join/#oe eFfeM (~frans@j200125.upc-j.chello.nl)
17:59.11*** join/#oe NightMonkey (debian-tor@pdpc/supporter/professional/nightmonkey)
18:01.00eFfeMgm
18:01.05kergoth_hey eFfeM
18:01.19eFfeMkergoth_ Hi!
18:02.03*** join/#oe marex (~marex@eduroam6.ms.mff.cuni.cz)
18:02.04eFfeMkhem, tried the gcc patch for mediatomb today, but not success, same failure (actually libgcc.so already seemed to have the proper info in it
18:03.04*** join/#oe stefan_schmidt (~stefan@p5B03683D.dip.t-dialin.net)
18:08.26CIA-10103Philip Balister <philip@balister.org> 07org.openembedded.dev * r604fe17b54 10openembedded.git/recipes/autoconf/autoconf.inc:
18:08.26CIA-101Revert "autoconf.inc: Use 'which' to find m4"
18:08.26CIA-101This reverts commit 8da17586c547f365ae667eb2608ba89a1c375afc.
18:08.26CIA-101This commit broke autoconf running on the target. I spoke with Tom Rini and he
18:08.26CIA-101approved the revert of his commit.
18:08.36CIA-10103Philip Balister <philip@balister.org> 07org.openembedded.dev * r5f62651cbf 10openembedded.git/recipes/uhd/uhd.inc: uhd : Fix packaging for examples and test programs.
18:13.44Crofton|workkhem, can you commit the fix you made for me yesterday?
18:13.49Crofton|workit looks good
18:19.24*** join/#oe mrj10 (~mrj10@63.252.64.254)
18:22.58*** join/#oe mrc3 (~ddiaz@189.157.106.95)
18:23.43*** join/#oe toi (~peter@d54C2AA76.access.telenet.be)
18:31.30CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * rc1d9a905c2 10openembedded.git/recipes/openssl/openssl.inc:
18:31.30CIA-101openssl: allow to add configure options through EXTRA_OECONF
18:31.30CIA-101Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
18:31.30CIA-101Acked-by: Michael Smith <msmith@cbnco.com>
18:31.49*** part/#oe mrj10 (~mrj10@63.252.64.254)
18:32.42woglindehms
18:32.52woglindeno rw for obi yet?
18:33.35*** join/#oe hansdampf (~moritz@212.77.182.171)
18:33.54obiwoglinde: i just pushed my second commit ;)
18:38.50woglindefine
18:41.02CMoHhmm... bitbake from git is a total mistery; nothing that worked still works
18:41.15kergoth_CMoH: what do you mean?
18:41.31CMoHwell, there's no more bitbake -i
18:41.45kergoth_that's correct, it doesn't exist in the 1.10 releases either
18:42.08*** join/#oe toi (~peter@d54C2AA76.access.telenet.be)
18:42.16kergoth_it will be resurrected in a better form in the future.  it can't be implemented the way it was anymore, due to architectural changes
18:42.20CMoHi see; well i just moved from my setup based on 1.8.18 to this git master
18:42.38CMoH1.11.0
18:42.41kergoth_that would be a massive change, yes.  the master branch was separated from 1.8 2 years before 1.10 finally released.
18:43.03CMoHstill it seems ubuntu and gentoo (also your openembedded manual) are all based on 1.8
18:43.48kergoth_OE doesn't require 1.10 yet.
18:43.53kergoth_so that's not too surprising
18:44.11kergoth_did you have an issue other than -i?
18:44.12CMoHyeah... humpf... and there are no layers or bbappend recipes in 1.8
18:44.28kergoth_that's not quite correct, they're just available in a different way
18:44.37khemCrofton|work: Can I add your Tested-by
18:44.46Crofton|workplease do
18:44.55kergoth_you'd probably want to leverage collections.bbclass and amend.bbclass if you want to use the 1.8 mechanisms, but since that's not the direction going forward, i wouldn't recommend it
18:44.56CMoHkergoth_, i'm very interested in what you mean
18:45.06CMoHi see
18:45.12kergoth_do a bit of googling for those, you'll find the instructions
18:45.34khemobi should send keys to cbrake or me
18:45.34CMoHso what's the direction you'd recommend?
18:45.34kergoth_er, sorry, its still collections.inc, not collections.bbclass.
18:45.35kergoth_use 1.10 or master and deal with the lack of -i.
18:45.38kergoth_would be my advice.
18:45.47CMoHah, that's the least of my problems :)
18:45.48kergoth_we're likely releasing 1.11 in the next few weeks
18:45.57kergoth_well, we can't fix problems without reports.
18:46.01kergoth_i haven't heard of any outstanding issues
18:46.11kergoth_there are a grand total of 2 people working on bitbake
18:46.21CMoHah, i'd better read the manual - first i wanted a confirmation that it's been really changed
18:46.23kergoth_well, 3 now
18:46.31CMoHgreat job!
18:46.54kergoth_i don't mind helping, if you're having trouble, just ask
18:47.19CMoHthanks - i will; though usually i try to find some docs first
18:47.36kergoth_you won't find much ;)
18:47.42kergoth_there's the OE manual, but beyond that..
18:47.50kergoth_the bitbake documentation is weak at best
18:48.46CMoHwell my first shock was ERROR: Nothing to do.  Use 'bitbake world' to build everything
18:49.06CMoHas far as i knew, i'd have to provide a package - where's the world thing coming from?
18:49.23eFfeMkhem any new clue on the mediatomb issue ?
18:49.28kergoth_what exactly was the bitbake command you ran?
18:49.44kergoth_that error will only happen if 1) your BBFILES isn't correct, or 2) you didn't specify a package
18:49.44CIA-10103Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * r9c3dfa69e8 10openembedded.git/recipes/at/ (at-3.1.12/at-parallel-make-fix.patch at_3.1.12.bb):
18:49.45CIA-101at 3.1.12: fix parallel make fix
18:49.45CIA-101Use dummy target to avoid race with double yacc invocation.
18:49.45CIA-101Signed-off-by: Roman I Khimov <khimov@altell.ru>
18:49.48CMoHjust bitbake
18:49.55CMoHtrue
18:49.55kergoth_well, what do you expect?
18:50.02kergoth_bitbake doesn't read your mind to know what you want to build
18:50.09CMoHlol, no
18:50.23CMoHis there any "world" recipe ?
18:50.41CMoHlike my portage world file
18:51.10*** join/#oe Heinervdm (~thomas@pD9E160FD.dip.t-dialin.net)
18:51.12Jay7world is reserved word :)
18:52.56khemeFfeM: is this recipe upstream ?
18:53.01eFfeMkhem, yes
18:53.41kergoth_world is magic
18:53.47CMoHwhat does it do?
18:53.54khemlet me try to reproduce it. If you are lucky I will reproduce it
18:53.55kergoth_it builds every provider, unless that provider is provided by multiple recipes, in which case it builds the preferred one
18:54.03eFfeMkhem: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/mediatomb/mediatomb_0.11.0.bb
18:54.07kergoth_so it builds everything, but for e.g. virtual/kernel, it only builds the preferred kernel
18:54.16CMoHi see
18:54.20kergoth_remember that bitbake was based on portage originally, so world *should* seem familiar to you
18:54.30CMoH:)
18:54.45eFfeMkhem, thanks (it is configure to find js), btw I compiled for armv5te (sheevaplug), distro minimal
18:54.50kergoth_also, this behavior was the same in 1.8.  you hvae to specify a package to build, and world builds everything
18:55.03kergoth_but remember that OE has, what, nearly 8,000 recipes or something now -- you *really* don't want to build world
18:55.20kergoth_it'll take a long time just to construct the runqueue to start the build, and the actual build is likely to take a week
18:55.20CMoHwell... my current real problem is bitbake console-image does nothing
18:55.25kergoth_what do you mean?
18:55.40kergoth_you're going to have to elaborate when you report a problem, ideally a pastebin of the exact output or error you're seeing
18:55.50CMoHnothing at all
18:55.54CMoHi get a new prompt
18:56.02khemeFfeM: as long as arch is arm it should be reproducable
18:56.03kergoth_interesting
18:56.06kergoth_try 1.10.
18:56.14kergoth_git checkout -b 1.10 origin/1.10
18:56.16kergoth_in the git repo
18:56.18CMoHbitbake -D console-image the same
18:56.19kergoth_then run it again
18:56.27eFfeMkhem, will try to create a small usecase using the code generated by configure
18:56.32CMoHkk
18:56.38kergoth_its likely that the error is occurring too early on, before the UI exists to display the error, a bug in bitbake
18:56.47kergoth_with 1.10 you're certain to see it, or nearly so
18:56.49CIA-10103Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r4537344b82 10openembedded.git/recipes/initrdscripts/initramfs-uniboot_1.0.bb:
18:56.50CIA-101initrdscripts/initramfs-uniboot_1.0.bb: DESCRIPTON -> DESCRIPTION
18:56.50CIA-101(saw this on the poky ML)
18:56.50CIA-101Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
18:57.00CIA-10103Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r2d32ea408f 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev
18:57.06khemeFfeM: well one way is that you add STAGING_DIR/lib to -L
18:57.37*** join/#oe bluelightning (~bluelight@cpc13-lewi14-2-0-cust559.2-4.cable.virginmedia.com)
18:57.37*** join/#oe bluelightning (~bluelight@pdpc/supporter/professional/bluelightning)
18:57.49khemeFfeM: its good to do git log before pushing
18:57.54eFfeMkhem, would that help? anyway it seems worth trying
18:58.37CMoHkergoth_, what is each of the UIs good for?
18:58.51CMoHncurses/depexp (which seems to like -g)/knotty
18:59.05kergoth_knotty is the default UI, the commandline, noninteractive one
18:59.15eFfeMkhem, true, actually did a pull just before it and forgot the --rebase (actually in config I also have autosetuprebase = always but that does not seem to work as I expected)
18:59.24eFfeMafk for a while
18:59.31kergoth_there's an ncurses one which isn't working at the moment, the idea with that one is its like the commandline one, but has a separate window for the current active tasks, and one to input commands like -i used to, but its not there yet
18:59.33CMoHi.e. the one you get when building a package off command-line or running other commands,
18:59.45kergoth_bitbake foo -> runs knotty
19:00.35*** join/#oe kevinsc1 (~a0214685@nat/ti/x-aprhdplwfxjlsqzl)
19:01.09CMoHi'll have to try 1.10 - using -u depexp -g i get a nice gtk-based window, next a progress bar "parsing metadata" and next a crash
19:02.21Crofton|workIf I run configure on the target, what does it use for CFLAGS?
19:02.34CIA-10103Martin Jansa <Martin.Jansa@gmail.com> 07master * rd1f84edcb2 10openembedded.git/recipes/webkit/ (4 files in 2 dirs):
19:02.34CIA-101webkit-efl: bump SRCREV and add patch for scrolling issue
19:02.34CIA-101Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
19:06.32kergoth_CMoH: knotty is the only one that's getting attention right now.
19:06.42kergoth_though the poky/yocto folks have done some work on goggle recently
19:06.53kergoth_so i take that back, but its still the primary
19:07.20kergoth_also, you shouldn't need -g if you're using depexp, they're independent pieces of functionality
19:16.10*** join/#oe guufy (~Guufy@c-24-130-108-191.hsd1.ca.comcast.net)
19:16.59CMoHyeah, before i handed it a package to build
19:17.35CMoHhmmm - it seems to work with 1.10.1
19:17.45CMoHerr 1.10.0
19:18.56*** join/#oe dijenerate (~dijenerat@65.48.156.82)
19:21.49CMoHi guess i'll see the results in 2-3 hours :(
19:23.23CMoHit's much faster than 1.8 though with runqueue and these things
19:24.05kergoth_master is faster yet than 1.10, particularly with the parsing.  not sure why you're seeing problems with it
19:24.49*** join/#oe rob_w (bob@pD95EF867.dip.t-dialin.net)
19:27.23*** join/#oe ashen (~ashen@62.209.230.82)
19:31.47CIA-10103Khem Raj <raj.khem@gmail.com> 07master * rc1facf79a2 10openembedded.git/recipes/js/js_1.5.bb:
19:31.47CIA-101js_1.5.bb: Beat it to respect LDFLAGS
19:31.47CIA-101* Fixes QA errors like below
19:31.47CIA-101ERROR: QA Issue with js: No GNU_HASH in the elf binary:
19:31.47CIA-101'/scratch/oe/work/armv7a-oe-linux-gnueabi/js-1.5-r2/packages-split/js/usr/lib/libjs.so'
19:32.13khemeFfeM: hmmm I have libtool 2.4 and mediatomb needs to update libtool macros I think
19:32.20khemso I get bitten
19:33.15Crofton|workkhem, I have another issue
19:33.26Crofton|work<PROTECTED>
19:33.30Crofton|workleads to failiure
19:33.32Crofton|workon target
19:34.06Crofton|workhttp://pastebin.com/2t6QAkBJ
19:35.09khemeFfeM: http://pastebin.com/kBLMTUxn
19:35.33khemCrofton|work: thats wrong usage for OE armv7/gcc
19:35.45khemwe dont support hard float abi
19:35.47khemyet
19:35.50Crofton|workwhat is the right usage
19:35.52khemI want to fo that
19:36.19khemjust gcc -v -o hello hello.c  should select correct float abi
19:36.36khem-mfloat-abi=softfp
19:36.42khemis the one you should use
19:38.08Crofton|workhmm
19:38.16Crofton|workI need to figure out why I am confused
19:39.08khemthere are two things one is presense of FP hardware itself second is using FP registers in ABI to pass function arguments
19:39.17Crofton|workyeah
19:39.29khemso you have two  params
19:39.37CMoHkergoth_, unfortunately i don't have the time to learn how to debug it in order to get you a good bug report
19:39.38Crofton|workok, there is code in tune-cortexa8 to switch it
19:39.43khem-mfpu and -mfloat-abi
19:39.45Crofton|workbut iti is still using softfp
19:39.49kergoth_CMoH: np, hopefully i'll run into it at some point
19:39.51CMoHbut if you assist me i'd be willing to do it
19:40.11khemmfpu tells the compiler that you can use fpu for generating code
19:40.16kergoth_i'm not sure how without sprinkling prints in the code :)
19:40.27ashenhi, it seems that anoncvs.handhelds.org(128.31.0.23):2401 is down so I can't fetch ipkg
19:40.30*** join/#oe dijenerate (~dijenerat@72.51.112.226)
19:40.38khem-mfloat-abi tells it that you should use FP registers according to ABI when passing params to functions
19:40.44Crofton|workyeah
19:40.48ashenas i really not care a about ipkg is there a way ho to disable building it? or build opkg instead?
19:40.52Crofton|workI have some understanding of the differences :)
19:41.01kergoth_it isn't fetching ipkg, its fetching ipkg-utils, most likely
19:41.05kergoth_we don't build ipkg anymore
19:41.08khem-mfloat-abi=softfp says that calling conventions do not use FP regs
19:41.11ashenyeah ipkg-utils, sorry
19:41.12CMoHkergoth_, is it possible to run bitbake from within the git repo? i mean without installing it into /usr etc
19:41.23Crofton|workCMoH, yes
19:41.35Crofton|workjust set your path to the git repo bitbake/bin I thinnk
19:41.38Crofton|workI do that
19:42.01kergoth_yep
19:42.13kergoth_at one time that was the only way to run it ;)
19:42.28Crofton|workonly crazy people install bitbake
19:42.33kergoth_hehe
19:42.34*** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian)
19:42.46CMoHlol
19:43.06kergoth_i really quite like the idea, but the problem is its disassociated from OE.  i'd really rather use buildout or git submodule or something in the oe repo to pull down exactly the version it needs, but..
19:43.09CMoHi'd also ask you on how to make a .deb off it (i'm not familiar with ubuntu but...)
19:43.39kergoth_the debian metadata isn't maintained upstream, the debian folks do it
19:43.53kergoth_you'd have to copy the debian dir from their source package and modify it to create a package for 1.10
19:45.07CMoHi see - thanks
19:49.06ashenso how can i get rid of ipkg-utils?
19:51.03kergoth_you don't.  its required to build opkg-based root filesystems
19:51.12kergoth_the tarball is available on our mirrors, as far as i know
19:51.19ka6soxthe native is
19:51.21kergoth_handhelds.org is down and isn't coming back, apparently.
19:53.36*** join/#oe pespin (~pespin@135.pool85-50-83.dynamic.orange.es)
19:54.35CMoHyup
19:54.44CMoHthe problem is in setup.py it seems
19:54.59CMoHi've updated bitbake-9999.ebuild to use the git repo
19:55.28CMoHnow running it directly from the git repository it works; installing it via the ebuild produces an unusable bitbake
19:56.20kergoth_what's the behavior?
19:56.33CMoHit does nothing
19:56.52kergoth_gah, we haven't killed those prints of unpackaged files, particularly in the kernel, yet?
19:56.58kergoth_this is agonizingly slow
19:57.48*** join/#oe GNUtoo|laptop (~gnutoo@50.118-226-89.dsl.completel.net)
20:00.56ashenkergoth_ thanks, so if I download it manually and put it in sources it bypass the do_fetch task?
20:01.19kergoth_ashen: yeah, do_fetch only fetches what it has to.  if its already there, it should skip it and move on
20:01.33*** join/#oe kevinsc (~a0214685@nat/ti/x-jinqnbkzfjuelqfr)
20:16.26*** join/#oe GNUtoo|laptop (~gnutoo@50.118-226-89.dsl.completel.net)
20:21.24ashenkergoth_: errr...got link to mirror with tarballs? I can't find anything;o/
20:25.01*** join/#oe morphis_ (~morphis@brmn-4dbc85b4.pool.mediaWays.net)
20:27.12*** join/#oe guufy (~Guufy@70-35-57-218.static.wiline.com)
20:34.39GNUtoo|laptopApplying patch fix-ecore-fb-initialization.patch fails...
20:34.42GNUtoo|laptopis it normal?
20:35.17GNUtoo|laptopis it a problem on my side(my computer just powered off due to empty battery)
20:38.27*** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net)
20:38.31*** join/#oe kristoffer (~kristoffe@c-1cdce555.010-30-6c6b7012.cust.bredbandsbolaget.se)
20:39.43*** join/#oe bluelightning (~bluelight@cpc13-lewi14-2-0-cust559.2-4.cable.virginmedia.com)
20:39.43*** join/#oe bluelightning (~bluelight@pdpc/supporter/professional/bluelightning)
20:45.55eFfeMkhem, was afk, thanks for the patch, thought it was a js issue, I have libtool 2.4 too, saw your pastebin, will give it a shot
20:46.02eFfeMthanks for your help
20:46.49*** join/#oe robtow (~a0272704@nat/ti/x-kisjezxdefvibmxb)
20:50.01*** join/#oe CruX| (~jozo@158.193.86.116)
20:50.16kergoth_decides to temporarily use github for the bitbake todo - https://github.com/kergoth/bitbake/wiki/TODO
20:52.06foersterkergoth_: looks good enough there
20:52.19foersternone of the other UIs work right now, I'm playing with them a bit
20:52.22*** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho)
20:53.04kergoth_cool, that's a good idea
20:53.36foersterthey all must be quite old - all reference MsgBase and puke, and event.sofar for ParseProgress
20:53.51kergoth_nods
20:54.01kergoth_current master has some updates for goggle from poky for some of that
20:54.06foersterok
20:54.10foersteri was just playing with goggle
20:54.15foersterperhaps i need to look at what they did
20:55.59kergoth_cute, i like that github backs their wikis with git
20:56.12Jay7have described how kexecboot works on kexecboot.org
20:56.57Jay7I need some native english speaker to fix texts there :)
20:57.04CIA-10103Eric Bénard <eric@eukrea.com> 07org.openembedded.dev * r8c56bc9a03 10openembedded.git/recipes/meta/meta-toolchain.bb: (log message trimmed)
20:57.04CIA-101meta-toolchain: fix directories rights
20:57.04CIA-101Actual sdk change rights of /usr and /usr/local to 775 when
20:57.04CIA-101untaring the archives with sudo ... giving group write access
20:57.04CIA-101to these directories.
20:57.13CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * ra5781edff2 10openembedded.git/recipes/opensync/msynctool_0.22.bb:
20:57.13CIA-101msynctool_0.22: fixed SRC_URI
20:57.13CIA-101Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
20:57.13CIA-101Signed-off-by: Eric Bénard <eric@eukrea.com>
20:57.18CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r157adffd31 10openembedded.git/recipes/asterisk/asterisk_1.2.24.bb: (log message trimmed)
20:57.18CIA-101asterisk_1.2.24: Set correct Checksum
20:57.18CIA-101Tilghman Lesher <tlesher@digium.com> wrote on asterisk-users@lists.digium.com:
20:57.18CIA-101Due to a licensing issue with some of the files we distributed with previous
20:57.18CIA-101tarballs, we removed those files from archived tarballs in order to avoid
20:57.26CIA-101u2nl_1.3: fixed SRC_URI
20:57.26CIA-101new version avalible.
20:57.27CIA-101Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
20:57.27CIA-101Signed-off-by: Eric Bénard <eric@eukrea.com>
20:57.28CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r21747e1784 10openembedded.git/recipes/redfang/redfang.bb:
20:57.28CIA-101redfang: fixed SRC_URI
20:57.29CIA-101Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
20:57.36CIA-101Signed-off-by: Eric Bénard <eric@eukrea.com>
20:57.36CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r2a53e4713e 10openembedded.git/recipes/dasher/dasher-gpe_0.0-svn.bb:
20:57.37CIA-101dasher-gpe_0.0-svn: fixed SRC_URI
20:57.37CIA-101Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
20:57.43foersterand goggle is broken afaik, even with their changes
20:57.46CIA-101Signed-off-by: Eric Bénard <eric@eukrea.com>
20:57.46CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r5a0067a970 10openembedded.git/recipes/esc/esc-gst_6.bb:
20:57.46CIA-101esc-gst_6: fixed SRC_URI
20:57.46CIA-101Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
20:57.46CIA-101Signed-off-by: Eric Bénard <eric@eukrea.com>
20:57.47CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r75abfabf5b 10openembedded.git/recipes/gtk2-ssh-askpass/gtk2-ssh-askpass_0.3.bb:
20:57.47CIA-101gtk2-ssh-askpass_0.3: fixed SRC_URI
20:57.55CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r038f37dc6c 10openembedded.git/recipes/litestream/litestream_1.3RC3.bb:
20:57.55CIA-101litestream_1.3RC3: fixed SRC_URI
20:57.56CIA-101Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
20:57.57CIA-101Signed-off-by: Eric Bénard <eric@eukrea.com>
20:57.57CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * rebf2b36c38 10openembedded.git/recipes/mathomatic/mathomatic_12.4.2.bb:
20:57.58CIA-101mathomatic_12.4.2: fixed SRC_URI
20:57.58CIA-101Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
20:57.59CIA-101Signed-off-by: Eric Bénard <eric@eukrea.com>
20:57.59CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * re4d21b8c78 10openembedded.git/recipes/esc/esc-media_5.bb:
20:58.07CIA-101Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
20:58.07CIA-101Signed-off-by: Eric Bénard <eric@eukrea.com>
20:58.08CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * rc8c00df694 10openembedded.git/recipes/maxima/maxima_5.21.1.bb:
20:58.08CIA-101maxima_5.21.1: fixed SRC_URI
20:58.09CIA-101Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
20:58.10CIA-101Signed-off-by: Eric Bénard <eric@eukrea.com>
20:58.10CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * rfb73531e5c 10openembedded.git/recipes/scsi-idle/scsi-idle_2.4.23.bb:
20:58.11CIA-101scsi-idle_2.4.23: fixed SRC_URI
20:58.11CIA-101Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
20:58.18CIA-101Signed-off-by: Eric Bénard <eric@eukrea.com>
20:58.18CIA-10103Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * rff004eb674 10openembedded.git/recipes/sidplay-base/sidplay-base_1.0.9.bb:
20:58.18CIA-101sidplay-base_1.0.9: fixed SRC:URI
20:58.18CIA-101Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
20:58.18CIA-101Signed-off-by: Eric Bénard <eric@eukrea.com>
20:59.10foersterkergoth_: the recent changes to goggle don't make it work in master, so I don't know what they were doing :)
20:59.39foersterin fact, the main culprit is RunningBuild, which references outdated event types
20:59.58kergoth_they were making it work with poky's bitbake, i would assume -- i'm sure there's more to be done to get it working with master from there
21:00.04foersterah
21:00.07foersteri'm on it
21:00.09kergoth_:)
21:00.21foersteris having fun not working on work stuff today
21:00.33ericbenkergoth_: foerster: what do you call ui when talking of bitbake ? (maybe stupid question sorry)
21:00.51kergoth_ericben: master supports multiple user interfaces.
21:01.04foersterkergoth_: not really :)
21:01.08kergoth_the default commandline one, as well as an X11 dependency explorer, a broken ncurses interface, etc
21:01.09foersterit's supposed to, but doesn't
21:01.12kergoth_well, in theory, it should
21:01.14kergoth_yeah :)
21:01.38ericbenkergoth_: ah ok. How can I try this ?
21:01.38foersteri'm going to fix up RunningBuild now to fix some of the problems
21:01.47kergoth_this is part of why i have thought the UIs should be separated from bitbake proper, as separate python scripts which import bb and do their thing
21:02.03kergoth_some of bitbake's commandline options make no sense for some UIs
21:02.30ericbenok bitbake -u things in lib/bb/ui
21:02.38foersterericben: yes
21:03.32kergoth_of course, we could always put the broken UIs on a branch, too -- nothing in the tree should be broken when we do a release
21:04.33foersterwell, we'll see if we can easily fix any of them
21:04.37kergoth_but, we're in danger of causing 'bitbake' to have more dependencies on python modules just for specific UIs, keeping them all in one repo
21:04.46kergoth_nods
21:05.11foerstereasiest way is to remove -u from options for now
21:05.22kergoth_that's true
21:05.36foersteror, only list knotty
21:05.51foersterif someone wants to run another, they can still specify it directly
21:05.56kergoth_thats probably best, as we know from -i, user's really dislike commandline options vanishing :)
21:06.04kergoth_s/'s/s/
21:06.33foersteryea, i see references to -i, but in docs and everything, but found that it doesn't exist
21:07.20kergoth_hmm, we could create a 'daemonize' UI, which spawns a bitbake server with an xmlrpc interface and prints the connection info, for use by potential non-python UIs (e.g. eclipse plugin)
21:07.28kergoth_(later on)
21:07.48foersteryes.
21:08.03*** join/#oe mrj10 (~mrj10@63.252.64.254)
21:08.22kergoth_of course, to do that either the process server would need an optional mechanism to add an xmlrpc server, or the UI would need to be the one controlling the spawn of the server
21:09.37*** join/#oe mwester (~mwester@nslu2-linux/mwester)
21:10.02*** join/#oe zenlinux (~sgarman@c-76-105-143-140.hsd1.or.comcast.net)
21:10.13GNUtoo|laptopis ecore broken?
21:10.45GNUtoo|laptopor is it me(computer battery finished in the middle of a build)
21:10.56GNUtoo|laptopApplying patch fix-ecore-fb-initialization.patch fails...
21:11.31ericbenGNUtoo|laptop: hi, what is the name of the recipe (I can try it now)
21:11.48GNUtoo|laptopelse I can try to fix
21:11.50GNUtoo|laptopecore_svn
21:11.53GNUtoo|laptopand look into it
21:12.00GNUtoo|laptopjust that I had other stuff to do
21:12.04GNUtoo|laptopsuch as going to bed
21:12.07GNUtoo|laptop(tired)
21:12.47GNUtoo|laptophi btw
21:16.03ericbencool pandaboard should ship in 3 days only 3  weeks late not bad
21:17.10ericbenGNUtoo|laptop: answer in a few seconds, other tasks are building and ecore should come soon
21:17.55GNUtoo|laptopok thanks
21:18.01ericbenGNUtoo|laptop: ecare is configuring so the patch seems to be applied
21:18.47GNUtoo|laptopah strange then
21:18.51GNUtoo|laptopI'll look
21:18.54ericbenGNUtoo|laptop: 1 second I was not on head
21:18.56GNUtoo|laptopthanks a lot
21:19.30GNUtoo|laptopI suspect packaging staging and already-applied patches
21:19.33ericbenGNUtoo|laptop: restarting build
21:19.42GNUtoo|laptopI cleaned and still nothing
21:20.06GNUtoo|laptopahhh ok
21:20.07GNUtoo|laptopsorry
21:20.13GNUtoo|laptopbasically I cleaned ecore
21:20.16GNUtoo|laptopand not ecore-native
21:20.22GNUtoo|laptopI only looked at the recipe name
21:20.28GNUtoo|laptopsorry
21:21.20ericben3622 tasks remaining I was on stable ;)
21:21.41ericbenso if you don't get news from me that means ecore_svn builds
21:23.16GNUtoo|laptopericben, ^^^
21:23.22GNUtoo|laptopshould be an error from my side
21:27.26CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * rf7f9648d31 10openembedded.git/recipes/vsftpd/vsftpd_2.0.5.bb:
21:27.26CIA-101vsftpd-2.0.5: don't run pkg_postinst on host
21:27.26CIA-101Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
21:28.58*** join/#oe Martin-B (~martin@pool-244-65-198-89.dbd-ipconnect.net)
21:31.20*** join/#oe mrc3_ (~mrc3@nat/ti/x-lsgwhovlgohfelhu)
21:31.58*** join/#oe Martin_B (~martin@pool-244-65-198-89.dbd-ipconnect.net)
21:32.55*** join/#oe CMoH-notebook (~cipi@95.76.74.1)
21:32.55*** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh)
21:33.42CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r186d009f4c 10openembedded.git/recipes/libsdl/pushover_0.0.1.bb:
21:33.43CIA-101libsdl: depend on virtual/libsdl instead of libsdl-x11
21:33.43CIA-101Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
21:33.45CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r1b5ee5b117 10openembedded.git/recipes/python/python-pygame_1.9.1.bb:
21:33.45CIA-101python: depend on virtual/libsdl instead of libsdl-x11
21:33.45CIA-101Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
21:33.48CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r618653b0b6 10openembedded.git/recipes/efl1/ecore.inc:
21:33.48CIA-101efl1: depend on virtual/libsdl instead of libsdl-x11
21:33.48CIA-101Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
21:33.50CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r561f8a77b5 10openembedded.git/recipes/vlc/ (vlc.inc vlc_0.9.2.bb):
21:33.51CIA-101vlc: depend on virtual/libsdl instead of libsdl-x11
21:33.51CIA-101Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
21:34.04CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r062dbf9ad8 10openembedded.git/recipes/quake/ (4 files):
21:34.04CIA-101quake: depend on virtual/libsdl instead of libsdl-x11
21:34.04CIA-101Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
21:34.16CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r18d59f5fad 10openembedded.git/recipes/ffmpeg/ (ffmpeg.inc ffmpeg_svn.bb):
21:34.16CIA-101ffmpeg: set default license to GPLv2+, because --enable-gpl is used.
21:34.16CIA-101* See http://www.ffmpeg.org/legal.html
21:34.16CIA-101Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
21:34.21CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * re9e434d00a 10openembedded.git/recipes/libtheora/libtheora_0.9+1.0alpha7.bb:
21:34.21CIA-101libtheora: depend on virtual/libsdl instead of libsdl-x11
21:34.21CIA-101Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
21:34.34CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * rba6079a882 10openembedded.git/recipes/nogravity/nogravity_2.0.bb:
21:34.34CIA-101nogravity: depend on virtual/libsdl instead of libsdl-x11
21:34.34CIA-101Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
21:34.46CIA-10103Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r6fccd90300 10openembedded.git/recipes/gstreamer/gst-plugins-bad_0.10.20.bb:
21:34.46CIA-101gst-plugins-bad: update EXTRA_OECONF (mjpegtools, sdl)
21:34.46CIA-101* Fix build with mjepegtools installed, by disabling mpeg2enc and mplex.
21:34.46CIA-101The configure script of gst-plugins-bad wants to use AC_TRY_RUN for
21:34.46CIA-101both of them, which doesn't work when cross-compiling.
21:36.21obican someone please comment on the future of CVS_TARBALL_STASH? i think it should at least be removed from the documentation and from local.conf.sample, if bitbake >= 1.10 doesn't support it
21:39.21TartarusWe need to set a flag day or something for dropping bitbake 1.8 support
21:39.29Tartarus(and thus bumping python min up too)
21:49.52Crofton|workTartarus, bug the tsc :)
21:52.39*** join/#oe mrc3__ (~mrc3@nat/ti/x-jjjenzbzipnodbec)
21:53.06tharveysome of the build systems I support use OpenDNS which unfortunately uses redirects on many HTTP errors.  This results in bitbake fetching the OpenDNS 'wrapper' as a source which then fails.  Would it make sense to use a wget FETCHCOMMAND that has --max-redirect=0 to avoid this?  any reason why this wouldn't be desireable for default behavior?
21:54.23mrj10tharvey: seems like it's conceivable that the canonical way to fetch a source may involve redirects
21:55.53mrj10it may be possible to traverse the redirect chain and keep bitbake updated with "the end of the linked list", but some package homes may update the redirect chain frequently
21:55.54tharveyyes, I suppose so
21:57.04mrj10URL restructuring, moving to a different hosting provider, redirect from http://path/to/server/latest to http://path/to/server/<filename of latest version of the package>, things like that
21:57.42mrj10maybe we could just look at the fetched source and do a sanity check to see if it is an error message or the legit tarball
21:57.57tharveyya... guess the best approach is to avoid using evil redirectors like opendns
21:57.59mrj10check to see if the "file" utility recognizes it as it's purported file type
21:58.13mrj10or if it's bigger than some nominal size, ~2KB
21:58.33TartarusYou know?
21:58.41TartarusOptional integrity checking would be great
21:58.56Tartarusand catch these
21:58.59tharveywouldn't want to avoid integrity check - in this case the fetch is foobar
21:59.17TartarusRight
21:59.23TartarusAnd the integrity check will catch
21:59.27tharveymore interested in detecting the bad fetch to go on and try a mirror instead of thinking its good
21:59.33tharveyoh... I follow
21:59.54tharveyyou mean bitbake check the md5 and if fail try a mirror before bailing?
21:59.58TartarusNo
21:59.59mrj10wait.  tharvey, how does it continue if the md5sum is foobared?
22:00.03TartarusI mean *.bz2 -> bzip2 -t
22:00.05Tartarusand so on
22:00.12foersterkergoth_: https://github.com/foerster/bitbake/commit/c5ec30133257d7cc1eda6fcec70dd4110e0769f4
22:00.24tharveymrj10, it doesn't continue - bitbake fails.  What I'm after is avoiding the failure by trying a mirror
22:00.32mrj10ah, i see
22:00.39tharveyTartarus, that would work...
22:00.47tharveylike that better than assuming a filesize
22:00.49mrj10strange that it doesnt do that already, seems like a good idea
22:02.48tharveyany bb'ers want to add that?  kergoth ? :)
22:05.14*** join/#oe ensc_ (~irc-ensc@p5DF2FB91.dip.t-dialin.net)
22:06.55*** join/#oe mrc3_ (~mrc3@nat/ti/x-owbklagurpphgpwc)
22:13.13*** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net)
22:18.14ericbenkhem: any idea concernign this gcc error : http://tinderbox.openembedded.net/public/logs/task/8666826.txt
22:18.18ericben?
22:20.18mrj10tharvey: is there any benefit to putting the filesize AND md5sum in the recipe, so for a particular failure you mostly know whether it is due to incorrect filesize or due to in-network or on-disk bit-flippage?
22:20.32ericbenkhem: where trying samba-3.5.6 I get this one : http://pastebin.com/yuiYX2CM
22:21.08tharveymrj10, that sounds like too much overhead to metadata - I like the optional quicktest of tarballs idea
22:21.54grgericben, run the gcc command from the command line and try to reduce the compiler flags to identify if there is a culprit
22:22.07foersterkergoth_: depexp back to life now too: http://erafx.com/tmp/screenshot-depexp.png  
22:22.15kergoth_nice
22:22.24ericbengrg: I'm trying to identify the reason
22:22.42kergoth_at some point itd be cool to create something that lets you visually  navigate the graphviz graphs, click around to get details, etc
22:22.50kergoth_someday..
22:23.03foersteryea.  Well, now that we have some good basics back to functional, that's a start!
22:23.10kergoth_yep, definitely
22:23.12mrj10tharvey: yeah, i agree, there are upsides but the overhead likely outweighs me
22:23.27*** join/#oe lamawithonel_ (~lucas@pool-74-96-184-82.washdc.fios.verizon.net)
22:23.39kergoth_just realized he forgot to add i18n stuff to the TODO.. unicode chars in variable names, translation of bitbake internal messages, etc..
22:23.46mrj10i'm checking now whether libmagic (what "file <filename" on Linux et al. uses) supports the source file types we care about
22:23.56foersterkergoth_: goggle works, but it doesn't show much data other than tasks running
22:24.15foersterdoesn't know what all it's supposed to do anyway
22:24.36kergoth_either
22:24.49kergoth_ugh
22:24.49foersterit used to capture MsgBase and take action based on MsgWarn, MsgError, etc
22:25.02foersterwere those moved elsewhere into other event classes, or what?
22:25.09kergoth_foerster: busybox do_configure hangs when using teh split server, not with master, somehow
22:25.09mrj10kergoth: do we need more features or a more specialized tool than what already exists for navigating large graphviz graphs?
22:25.24foersterkergoth_: fml
22:25.25foerster:)  
22:25.26kergoth_foerster: we use LogRecord from the python logging module now, it carries a log level which translates to debug/warn/error/etc
22:25.34foersteris it T status?
22:25.40kergoth_yep
22:25.43mrj10e.g. http://code.google.com/p/jrfonseca/wiki/XDot , http://zvtm.sourceforge.net/zgrviewer.html http://www.kde.org/applications/graphics/kgraphviewer/
22:25.49foersterhow many levels deep?
22:25.55foersterphp 5.3.3 does that to me
22:25.57foersterevery time
22:26.00kergoth_too many
22:26.01kergoth_:)
22:26.03foersterbut not in master
22:26.14kergoth_the last 5 levels of processes are all T
22:26.18foersteri think it's doing it -- thinking we're a fork bomb maybe?
22:26.22kergoth_hmm
22:26.37kergoth_the weird thing is, the only difference between this and master is *ONE* extra process
22:26.41kergoth_wtf?
22:26.44foersteri know
22:27.04foersteri have a new php recipe here for newest version which does the exact same.
22:27.07foersterno idea why
22:27.17kergoth_maybe i should try a runqueue rewrite sooner rather than later, persist the workers in a pool, no re-forking for every task
22:27.22kergoth_see if that helps
22:28.26foersternot sure, that's some bullshit though if the system thinks we're forkbombing :)
22:28.52foersterlimit of num processes is umlimited here, so i dunno
22:30.05kergoth_yeah, very strange.  my first thought was it was an attempted read from stdin -- do_configure's can hang that way if they prompt blind instead of checking to see if its a tty
22:30.11kergoth_but that wouldn' tmake any sense given master works
22:30.36foersterright, nothing in that regard changed
22:31.35*** join/#oe julian_ (~julian@cpc3-cmbg14-2-0-cust129.5-4.cable.virginmedia.com)
22:31.43kergoth_(speaking of which, the way bb.build handles all the file descriptor stuff is ugly as hell, we need to get that stuff using subprocess)
22:32.01foersterI haven't even looked in there yet
22:32.23kergoth_does dup'ing of fds to get them redirected to the log or tee
22:32.34kergoth_pre-subprocess that was probably a fine way to get it done, but..
22:33.07kergoth_this T thing is just strange. hmm
22:33.10kergoth_googles
22:33.21foersteri couldn't find anything
22:33.28kergoth_:(
22:33.37foersterthe processes are being sent a SIGSTOP (or SIGTOSTOP, etc)
22:33.42foersterbut i have no idea how to find out who
22:34.03kergoth_my guess would be the kernel or the shell
22:34.24foersterhm
22:35.11*** join/#oe ant__ (~andrea@host247-251-dynamic.14-87-r.retail.telecomitalia.it)
22:35.35mrj10tharvey: python-magic provides bindings to libmagic, which looks to support all the filetypes we need (mostly just gzip and bzip2).  would need to ascertain whether a (optional, perhaps) dependence on that would be acceptable.  if not, i think we can implement simple magic-number-based tests ourselves for the small subset of source types we care about
22:36.29foersterlet me know if you can find anything.  This is the last biggie I think there is with the process server :)
22:36.33foersteri'm out for now
22:36.34tharveysound more reasonable than looking for filename extensions
22:36.34foersterlater
22:36.48kergoth_later
22:37.52mrj10yeah, it can detect a broader range of nefariousness on the part of your DNS provider, ISP, or other intermediaries (airport wifi gateway)
22:40.32kergoth_heh, gotta love it when you wget a tarball and get an html file
22:40.47tharveyreally annoying for sure
22:42.08tharveykergoth_, what do you think about an optional per-type integrity check based off the magic of the file?
22:42.24kergoth_doesn't seem unreasonable
22:42.46kergoth_i have a patch somewhere that implements do_unpack using python's modules for it, sadly too slow, but checking integrity likely isn't
22:45.36mrj10just checking the magic gets you 99.9% of the way there, it seems like
22:45.48kergoth_nice
22:47.32mrj10well, it might be useful to differentiate between a valid .bz2 file that just happens not to pass md5sum, which might indicate some URL changes on the server, and something that's not a .bz2 file at all
22:48.19mrj10doesn't seem like you'd have bitbake actually *do* anything different for one vs. the other, but you could have a more informative error message
22:48.22kergoth_all of the fetching and unpacking stuff is likely to be rewritten in the near future
22:48.39tharveywhat are those of you with ancient build systems using for the python2.6 requirement for bitbake master?  my u7.10 system doesn't have packages for it - not sure if its a can of worms to build and install manaully
22:48.41kergoth_bb.fetch is being replaced by a new module which handles fetching and unpacking, so is able to be smarter about "unpacking" things like scm repositories
22:48.58mrj10oh, nice
22:49.19kergoth_tharvey: i found a buildout that builds a local python of whatever version you like, and gives you a virtualenv for it
22:49.26kergoth_that's what i usually use, personally
22:49.48tharveysounds reasonable.... do you recall where you got it?
22:50.12tharveyheh... my build system is getting more and more archaic and difficult to deal with - I'm going to be at a full chroot soon
22:50.24tharveyin fact I would switch now if there was a quick simple howto for that
22:51.01kergothif all you want is a chroot from a debian based system, its pretty straightforward
22:51.04kergothdebootstrap to build it
22:51.15kergoththen i usually use schroot to enter it, since it manages the bind mounts for /proc, etc automatically
22:51.22*** join/#oe mrc3_ (~mrc3@nat/ti/x-onhafcnjvkfmquhj)
22:52.05kergoththarvey: http://svn.plone.org/svn/collective/buildout/python
22:52.33kergoththen edit buildout.cfg and you can see what python versions it'll build, i just killed all but the one i wanted
22:52.38kergothboth under extends and parts
22:52.45kergoththen python bootstrap.py; bin/buildout
22:52.48tharveyso basically you install a VM of a debian ver that you want, then use debootstrap on it?  are there bootstrap readily avail to avoid the process of setting up the VM?
22:53.16kergothwhat distro are you running?
22:55.13tharveyubuntu
22:55.19*** join/#oe Splat1 (~Splat1@rf1.splat1.com)
22:56.19tharveyubuntu has debootstrap pkg but I was more curious how I could get a quick for example u8.04 bootstrap w/o creating an u8.04 vm
22:56.47tharveyliked your previous reasons for building on an 'old' system, but perhaps not as old as my current u7.04 system :P  (I don't have perms to update it)
22:59.14CIA-10103Philip Balister <philip@balister.org> 07org.openembedded.dev * r5806128d5b 10openembedded.git/recipes/uhd/uhd_git.bb: uhd : Bump SRCREV to pick up latest uhd fixes.
22:59.15CIA-10103Philip Balister <philip@balister.org> 07org.openembedded.dev * r6c0ce137ba 10openembedded.git/recipes/autoconf/autoconf.inc: autoconf : Bump PR after earlier revert.
23:01.58*** join/#oe timtimred (~meh@79-67-226-227.dynamic.dsl.as9105.com)
23:02.44kergoth_tharvey: debootstrap can build either debian or ubuntu chroots of a variety of versions
23:02.55kergoth_hmm
23:03.02kergoth_not sure how old they go though
23:03.21kergoth_for rpm based distros there are a few similar tools, febootstrap, mock, etc
23:03.32kergoth_was trying to construct a set of useful chroots at one point
23:04.05tharveyah... I thought it just built from your host system - I'll read up on it - thanks
23:04.09kergoth_for debian i have.. etch, lenny, potato, sarge, sid, squeeze, and woody
23:04.18*** join/#oe pidge (~eflanagan@134.134.137.73)
23:04.21kergoth_no, it pulls the packages from the apt feeds for what its building
23:05.33tharveywhat is diff between debootstrap and cdebootstrap?
23:05.40kergoth_no idea :)
23:05.48kergoth_last time i tried the c one though it didn't have the config files necessary to do much
23:05.52kergoth_i'd stick to the regular one
23:05.55tharveyk
23:06.18kergoth_do a dpkg -L debootstrap|grep debootstrap/scripts
23:06.23kergoth_those are the ones you have to choose from
23:06.35kergoth_or ls /usr/share/debootstrap/scripts ;)
23:14.06*** join/#oe dromede (~quassel@93-136-69-203.adsl.net.t-com.hr)
23:24.45*** join/#oe dth (~dth@a89-183-4-63.net-htp.de)
23:24.49*** part/#oe dth (~dth@a89-183-4-63.net-htp.de)
23:25.24kergoth_ah ha
23:25.50kergoth_Some signals cause a process to stop: SIGSTOP (stop!), SIGTSTP (stop from tty: probably ^Z was typed), SIGTTIN (tty input asked by background process), SIGTTOU (tty output sent by background process, and this was disallowed by stty tostop).
23:25.58kergoth_SIGTTIN looks promising here
23:26.07kergoth_the question is why the behavior would be different with the server
23:26.08kergoth_hmmmm
23:30.38kergoth_oh fuck it, i'm changing bb.build to use subprocess
23:31.02Crofton|workarg
23:31.19Crofton|worki2c-dev.h gets staged from two packages it appears
23:31.58*** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz)
23:34.26Jay7kergoth_: is bb master usable now?
23:50.11kergoth_Jay7: should be, yes
23:50.17kergoth_its all i use
23:50.29Jay7ok, I'll run TB tonight
23:50.50Jay7will build images for my zauruses to test on real HW
23:50.55Jay7weekend is coming :)
23:52.07kergoth_:)
23:52.11Jay7seems perl is problem for yocto/poky too
23:54.10Crofton|workPeople who write Makefiles by hand should be shot
23:54.40Crofton|worki2c-tools installs a file called i2c-dev.h into include/linux
23:54.47Crofton|workover writing the version from the kernel
23:54.54kergoth_there we go
23:55.03kergoth_bb.build uses bb.process, which is oe.process, which uses subprocess
23:55.04kergoth_:)
23:55.16kergoth_*much* simpler
23:55.52*** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz)

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