00:01.10 | Crofton | Tartarus, I softlinked perl so it ran, which led to http://pastebin.com/NmWMNq7X |
00:01.31 | Tartarus | So it's still there,ok |
00:01.37 | Tartarus | But... why |
00:02.42 | Tartarus | But it really does all work if you undo 8da17586c547f365ae667eb2608ba89a1c375afc ? |
00:05.53 | Crofton | I am thinking about trying that .... |
00:06.02 | Crofton | it worked last month :) |
00:07.55 | coreyfro | Can 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.01 | coreyfro | I 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.46 | khem | coreyfro: this is not a paid support channel first of all. So writing in CAPS can throw off people |
00:10.18 | grg | coreyfro, 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.21 | kergoth_ | damnit |
00:11.23 | kergoth_ | hmm |
00:11.29 | coreyfro | Thanks GRG, I'll take a look |
00:14.33 | coreyfro | Is 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.07 | coreyfro | Or at least following those directions alone has not resulted in a built kernel |
00:15.54 | khem | documentation 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.18 | khem | are you using OE master or some offshoot |
00:16.22 | Crofton | if we had good documentation, no one would pay us for consutling |
00:16.41 | coreyfro | khem: OE master |
00:16.45 | Crofton | hopes coreyfro has a sense of humour |
00:16.59 | Crofton | coreyfro, did you find xoras blog entry on this |
00:17.20 | coreyfro | Crofton: I've worked for the feds, either I do, or I don't have feelings, so it doesn't matter |
00:17.36 | khem | coreyfro: ok, usually machine maintainers should have added a working defoconfig to relevant kernel |
00:17.38 | coreyfro | No, but I'm going to go look for it |
00:17.54 | Crofton|work | http://www.xora.org.uk/2009/12/10/openembeddedangstrom-kernel-workflow/ |
00:18.01 | Crofton|work | he's asleep now |
00:18.04 | Crofton|work | or drunk |
00:18.06 | Crofton|work | or both |
00:18.34 | kergoth_ | sighs, just ran into a deadlock in bitbake using the separated ui branch + his changes when its limited to just one processor |
00:18.41 | kergoth_ | grumbles |
00:18.42 | Crofton|work | heh |
00:18.45 | Crofton|work | tough stuff |
00:19.06 | Crofton|work | I hope to run the device driver I jsut "finished" on a multi core arm one day |
00:19.14 | Crofton|work | I suspect that will be very educational |
00:19.16 | kergoth_ | 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.34 | Crofton|work | Tartarus, do you want me to revert that changeset and see if things work |
00:19.39 | kergoth_ | prefers mostly collaborative multitasking with explicit communications channels |
00:19.43 | kergoth_ | messaging > shared |
00:20.20 | khem | needs some article to read during the light rail ride |
00:20.39 | khem | coreyfro: which kernel version is it building |
00:21.40 | coreyfro | Ok, I found a defconfig for Beagleboard in recipes/linux/linux-omap-2.6.32 |
00:21.46 | khem | linux-omap_2.6.29.bb seems to have preference |
00:22.27 | coreyfro | unfortunetly, I need the thin wifi firmware for Overo, which means I need the later kernels |
00:22.32 | khem | coreyfro: look in your build tree and see which version is it choosing |
00:22.37 | coreyfro | And I got it working, I just don't remember how |
00:23.21 | coreyfro | I built the kernel and configured it myself following http://www.openembedded.org/index.php/Kernel_Building |
00:23.29 | Crofton|work | khem, your fix looks good |
00:23.40 | khem | Crofton|work: thank you |
00:23.56 | coreyfro | I don't believe it built a kernel, I've always built it alone |
00:23.59 | khem | I now need confirmation from ericben and effem for their fixes then I can commit all 3 in one |
00:24.39 | kergoth_ | 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.58 | coreyfro | You 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.12 | khem | heh |
00:25.14 | kergoth_ | of course it does. it has *EVERYTHING* to do with this |
00:25.24 | kergoth_ | machine is what controls which kernel is built and what config is used for it |
00:25.45 | coreyfro | hah, but I am building for an overo |
00:26.03 | Crofton|work | khem, no |
00:26.03 | coreyfro | and overo isn't working |
00:26.05 | Crofton|work | failed again |
00:26.13 | Crofton|work | khem, sorry I was premature |
00:26.16 | coreyfro | lemme see if that makes it work |
00:26.27 | khem | Crofton|work: ok now on your target |
00:26.35 | Crofton|work | ok |
00:26.37 | khem | find . -name "libgcc_s.so" |
00:26.47 | Crofton|work | doh |
00:26.49 | Crofton|work | wait a minute |
00:26.58 | Crofton|work | wrong window |
00:27.00 | Crofton|work | sorry :) |
00:27.01 | khem | I mean find / -name "libgcc_s.so" |
00:27.10 | Crofton|work | I looked at the old failure :) |
00:27.16 | Crofton|work | it is still going |
00:27.24 | Crofton|work | needs to take a break |
00:27.29 | khem | see's crofton's wiggly eyes |
00:27.42 | Crofton|work | I just had it up to see where the failure was |
00:27.43 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
00:27.53 | khem | ok so it worked or not ? final answer |
00:27.54 | Crofton|work | I am 99% certain the build is past it now |
00:28.03 | Crofton|work | 99% certain fix is good |
00:28.17 | khem | ok I will grab a tea and see if 1% is falling on me |
00:28.24 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * rfc64eff03f 10bitbake.git/lib/bb/ (command.py cooker.py): |
00:28.25 | CIA-101 | cooker: add shutdown/stop methods |
00:28.25 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
00:28.26 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * rc7c8945ef7 10bitbake.git/lib/bb/ (command.py cooker.py): |
00:28.26 | CIA-101 | cooker: merge cookerState and cookerAction |
00:28.26 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
00:29.05 | coreyfro | Are any of you in the SF bay area? We have a new Embedded Linux group at Noisebridge |
00:29.20 | coreyfro | We meet on thursdays |
00:30.50 | Crofton | I am there sometimes |
00:30.58 | Crofton | khem works there |
00:32.51 | Jay7 | -> sleep |
00:39.18 | kergoth_ | oh son of a bitch |
00:39.20 | kergoth_ | sighs |
00:44.50 | kergoth_ | okay, this will work around it for now.. hrm |
00:49.24 | kergoth_ | i really hate ^C. |
00:51.16 | kergoth_ | argh |
00:56.13 | khem | coreyfro: oh TinyTux thing |
00:56.49 | khem | coreyfro: Allison mentioned it on our meetup for Silicon Valley Linux Technology group |
00:57.14 | khem | coreyfro: I am in San Jose and hate the commute to city |
00:57.39 | khem | unless it was somewhere local it would be interesting |
01:00.46 | *** join/#oe fraxinath (~quassel@p4FD65AA1.dip.t-dialin.net) |
01:03.02 | coreyfro | khem, then you should check out hackdojo. It's the baby of David Weekly of PBWIKI and Super Happy Dev House fame |
01:03.20 | coreyfro | khem: So, the beagleboard kernel works on my overo |
01:03.27 | khem | coreyfro: ok enjoy |
01:03.28 | coreyfro | but not my overo kernel |
01:03.42 | khem | coreyfro: I talk at SVLT few times thats all |
01:03.57 | khem | on various things related to embedded lnx |
01:04.26 | kergoth_ | sighs at bitbake |
01:04.43 | kergoth_ | can see the attraction of a rewrite :| |
01:10.45 | Crofton|work | notes kergoth_ has said that for years |
01:10.54 | kergoth_ | nods |
01:11.00 | kergoth_ | still true |
01:13.21 | kergoth_ | 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.41 | khem | kergoth_: rewrite is probably harder but refactoring can lead to rewrite over a period of time |
01:15.02 | kergoth_ | yeah, thats the goal, but its slow going, and frustrating at times |
01:15.08 | khem | I know |
01:15.10 | khem | :) |
01:15.30 | khem | I am starting a branch for recipes layers |
01:15.32 | kergoth_ | the worst is the lack of unit tests. refactoring without unit tests is MADNESS |
01:15.37 | khem | on lines with poky |
01:16.05 | kergoth_ | looked at koen's angstrom repo? might want to build on that |
01:16.08 | khem | yeah unit test is must actually its never late it needs to be started at some point |
01:16.46 | kergoth_ | its tough to add them when the components are so intertwined though :( |
01:16.55 | kergoth_ | need to refactor to unit test to refactor |
01:16.57 | kergoth_ | or something |
01:17.01 | kergoth_ | :) |
01:17.13 | khem | koen layed on top of poky isnt it |
01:17.53 | kergoth_ | 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.03 | khem | right |
01:18.17 | khem | what I am gonna try is create same structure within OE |
01:18.26 | khem | and use OE recipes |
01:18.51 | khem | we can then easily plugin yocto into core or out of core |
01:19.01 | kergoth_ | should probably focus on the bits that aren't already in yocto/poky then, eh? |
01:19.02 | kergoth_ | hmm |
01:19.02 | khem | whatever we decide |
01:19.04 | kergoth_ | its a good idea |
01:19.45 | khem | we can fine tune the layers later |
01:19.54 | khem | as we go |
01:20.03 | kergoth_ | going to go category based, graphics, multimedia, etc? |
01:20.08 | khem | yes |
01:20.09 | kergoth_ | i'd think itd be the best route |
01:20.23 | kergoth_ | outside of the distro/machine layers, anyway |
01:20.36 | khem | yes |
01:20.49 | khem | the machine/distro thing will be next |
01:21.30 | khem | I dont know if git will let me sync update into moved trees |
01:21.35 | khem | I mean dirs |
01:22.04 | kergoth_ | 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.05 | khem | if not then one day we have to have a flag day |
01:22.19 | kergoth_ | the problem is updating filter-branch'd branches from upstream |
01:22.23 | kergoth_ | thats a nightmare |
01:22.24 | kergoth_ | hmm |
01:22.30 | kergoth_ | and just mv'ing is worse |
01:22.33 | kergoth_ | due to conflicts |
01:22.34 | kergoth_ | hmm |
01:22.48 | khem | yeah so prolly I have to work on master |
01:22.55 | khem | and seep in the changes |
01:23.43 | kergoth_ | hmmm |
01:24.02 | kergoth_ | 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.00 | khem | I think if git could identify moved files it will be nice |
01:25.14 | kergoth_ | it can, but i'm not sure how smart it is about merges with them |
01:25.28 | khem | yeah need to see |
01:25.41 | khem | last time I tried something like that it did not go well |
01:25.47 | khem | I had to rename and commit |
01:25.54 | khem | push |
01:26.27 | kergoth_ | 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.32 | kergoth_ | 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.46 | fidencio | JaMa|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.39 | CIA-101 | 03Khem Raj <raj.khem@gmail.com> 07master * r8805bb48b9 10openembedded.git/recipes/binutils/ (13 files in 2 dirs): |
03:06.39 | CIA-101 | binutils-2.21: Add recipes for binutils 2.21 release |
03:06.39 | CIA-101 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
03:06.51 | CIA-101 | 03Khem Raj <raj.khem@gmail.com> 07master * r6454b9669d 10openembedded.git/recipes/binutils/binutils_git.bb: |
03:06.51 | CIA-101 | binutils_git.bb: Move to master now that 2.21 is released |
03:06.52 | CIA-101 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
03:07.57 | *** join/#oe jmpdelos (~polk@outgoing.delos.com) |
03:08.49 | CIA-101 | 03Joshua Lock <josh@linux.intel.com> 07master * r6c086dab25 10bitbake.git/lib/bb/cooker.py: (log message trimmed) |
03:08.49 | CIA-101 | bitbake/cooker: fix idle command processing in servers |
03:08.49 | CIA-101 | idle command processing in each of the servers does not handle an explicit |
03:08.49 | CIA-101 | None return value, which means the goggle UI ends up repeatedly adding |
03:08.49 | CIA-101 | "Tasks Summary:" rows to the list. |
03:08.56 | CIA-101 | 03Joshua Lock <josh@linux.intel.com> 07master * r38f59ad6db 10bitbake.git/lib/bb/ui/crumbs/runningbuild.py: |
03:08.56 | CIA-101 | bitbake/crumbs: do the test for ignored messages sooner |
03:08.56 | CIA-101 | Move the test for ignored messages to the start of the message handling loop to |
03:08.56 | CIA-101 | avoid doing work for messages which are only going to be ignored. |
03:08.56 | CIA-101 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
03:09.07 | CIA-101 | bitbake/goggle: interaction tweaks |
03:09.07 | CIA-101 | Set the goggle window to a more sane default size (640x480) and hook up the |
03:09.07 | CIA-101 | close button. |
03:09.07 | CIA-101 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
03:09.07 | CIA-101 | 03Joshua Lock <josh@linux.intel.com> 07master * rd2c4d0b2af 10bitbake.git/lib/bb/ui/crumbs/runningbuild.py: |
03:09.14 | CIA-101 | Due to some recent change *somewhere* we need to explicitly look at the |
03:09.14 | CIA-101 | name attribute on the instances class, rather than the name attribute of |
03:10.01 | CIA-101 | the instance. |
03:10.01 | CIA-101 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
03:10.01 | CIA-101 | 03Joshua Lock <josh@linux.intel.com> 07master * r0debaba644 10bitbake.git/lib/bb/server/xmlrpc.py: (log message trimmed) |
03:10.01 | CIA-101 | bitbake/xmlrpc: Modify xmlrpc server to work with Python 2.7 |
03:10.02 | CIA-101 | Python 2.7's library changes some of xmlrpclib's internal implementation such |
03:11.02 | CIA-101 | Signed-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.13 | CIA-101 | 03Richard Purdie <rpurdie@linux.intel.com> 07master * r6b6ae76ba5 10bitbake.git/lib/bb/data_smart.py: |
04:25.13 | CIA-101 | bitbake/data_smart: Refactor _append/_prepend code to remove duplication |
04:25.13 | CIA-101 | Signed-off-by: Richard Purdie <rpurdie@linux.intel.com> |
04:25.19 | CIA-101 | 03Richard Purdie <rpurdie@linux.intel.com> 07master * rba95240541 10bitbake.git/lib/bb/data_smart.py: (log message trimmed) |
04:25.19 | CIA-101 | bitbake/data_smart: Fix append/prepend/override ordering issue |
04:25.19 | CIA-101 | Where a variable name consisted of an append/prepend combined with an override |
04:25.19 | CIA-101 | and there was also an append/prepend to the variable, the override could be lost |
04:25.19 | CIA-101 | if 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.57 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * r5670134ab2 10bitbake.git/lib/bb/taskdata.py: |
05:33.58 | CIA-101 | cooker: use re match, not search in re_match_strings |
05:33.58 | CIA-101 | We want to match the requested pattern at the beginning of the string, |
05:33.58 | CIA-101 | otherwise things behave in an unintuitive manner wrt ASSUME_PROVIDED (e.g. |
05:33.58 | CIA-101 | ASSUME_PROVIDED += "gtk+" will also assume foo-gtk+ is provided), and the user |
05:34.08 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * re48e9a2150 10bitbake.git/lib/bb/taskdata.py: |
05:34.08 | CIA-101 | taskdata: use 'any' in re_match_strings |
05:34.08 | CIA-101 | Signed-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.54 | eFfeM_work | gm |
06:43.12 | JaMa|Zzz | fidencio: hey! :) |
06:48.20 | CIA-101 | 03Khem Raj <raj.khem@gmail.com> 07master * r55b4c60e08 10openembedded.git/recipes/binutils/ (binutils-cross-sdk_2.21.bb binutils-cross_2.21.bb): |
06:48.20 | CIA-101 | binutils-cross-sdk_2.21.bb,binutils-cross_2.21.bb: Use binutils_2.21.bb instead of git version |
06:48.20 | CIA-101 | Signed-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.19 | ericben | hi khem |
07:32.26 | ericben | good morning |
07:34.14 | ka6sox | khem, patches looks good. |
07:34.33 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
07:36.00 | ericben | release 2010.12 is in today's LWM weekly letter, in the "Brief Items" section |
07:37.16 | ericben | khem: 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.22 | mckoan | good morning |
08:10.13 | *** join/#oe guufy (~Guufy@c-24-130-108-191.hsd1.ca.comcast.net) |
08:11.40 | mckoan | This morning the server power supply has decided to infect the entire office with his stinks, a prelude to a fire :-D |
08:13.04 | mckoan | replaced 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.22 | ka6sox | mckoan, 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.59 | JaMa | someone 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.45 | mckoan | JaMa: may happen, but I'm not sure |
10:15.26 | JaMa | mckoan: it's hanging forever after showing |
10:15.32 | JaMa | "Starting kernel" here |
10:15.53 | mckoan | JaMa: so may be the kernel and not uboot |
10:17.39 | JaMa | same kernel binary for both u-boots |
10:18.13 | JaMa | also current toolchain makes it 10kB smaller.. |
10:19.35 | mckoan | JaMa: 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.36 | dreadrasta | hi everyone |
10:44.57 | dreadrasta | i just build environment oe |
10:45.07 | dreadrasta | i have a question |
10:45.33 | dreadrasta | i use linux- ubuntu on ARM |
10:45.50 | dreadrasta | there is any distro for it |
10:45.57 | dreadrasta | in oe |
10:46.01 | dreadrasta | recipes |
10:46.52 | *** join/#oe likewise (~likewise@205-89-ftth.onsneteindhoven.nl) |
10:48.39 | likewise | gm |
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.25 | tasslehoff | is 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.02 | likewise | tasslehoff: I think yes |
11:56.14 | likewise | tasslehoff: maybe a stable branch will follow on that release |
11:56.37 | likewise | tasslehoff: good question though, I will address it |
11:57.27 | tasslehoff | likewise: cool. we're planning a release in march, and I'm pondering if I should follow dev or stay stable :) |
11:58.34 | CIA-101 | 03Daniele Ricci <daniele.athome@gmail.com> 07master * r61cf049e1d 10openembedded.git/recipes/freesmartphone/libfreesmartphone-glib_git.bb: |
11:58.34 | CIA-101 | libfreesmartphone-glib: bump SRCREV and version, now depends on fso-specs |
11:58.34 | CIA-101 | Signed-off-by: Daniele Ricci <daniele.athome@gmail.com> |
11:58.34 | CIA-101 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
11:58.41 | tasslehoff | I see there's a branch at the same point as the tag now. |
11:58.46 | CIA-101 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r84ab2a190e 10openembedded.git/recipes/freesmartphone/ (fso-specs_git.bb libfso-glib_git.bb): |
11:58.46 | CIA-101 | fso-specs,libfso-glib: bump SRCREV and PV |
11:58.46 | CIA-101 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
11:59.35 | JaMa | tasslehoff: tag it's finall, branch will be probably removed later |
12:01.41 | likewise | JaMa: my proposal: can we rename or fork the branch so that we can do 2010.12.1 ? |
12:02.12 | likewise | i.e. so that 2010.12 is the first release, and also the branch root for stable bug fixes only. |
12:03.35 | JaMa | I 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.58 | JaMa | I guess nobody volunteered to maintain such branch |
12:04.45 | likewise | JaMa: it was decided that the actual users maintain it |
12:04.56 | likewise | jama: so not pre-assigned people |
12:04.59 | JaMa | yes that's why SHR has shr/testing2011.1 |
12:05.09 | JaMa | which is based on this tag |
12:07.09 | tasslehoff | Thanks for clarifying. |
12:16.32 | Crofton|work | jama 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.11 | likewise | Crofton|work: I'm not sure if that's true. We never spoke with any. |
12:19.39 | likewise | Crofton|work: that issue was mainly brought up by the maintainer police. |
12:19.50 | Crofton|work | notes constant low level chatter about the stable branch from people who do not like ho w it is maintained |
12:21.58 | likewise | Crofton|work: that's because currently the people who chatter are not maintaining it |
12:22.14 | likewise | Crofton|work: I think we should simply put the users in command |
12:23.06 | Crofton|work | exactly |
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.28 | foerster | | 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.39 | kergoth | also strange. best clean first -- it shouldn't behave any differently from a build perspective under taskset or not under taskset |
14:05.19 | foerster | cleaning, will try again |
14:06.38 | foerster | still fails, weird |
14:07.40 | foerster | Bear 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.47 | foerster | from py docs |
14:08.00 | kergoth | right |
14:08.45 | kergoth | thats 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.51 | kergoth | shrugs |
14:08.59 | kergoth | oddly fun to work on this sort of problem |
14:09.00 | foerster | hm. |
14:09.10 | foerster | right, though also annoying ;) |
14:09.19 | kergoth | indeed |
14:10.15 | kergoth | what 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.21 | foerster | "Remember also that non-daemonic processes will be automatically be joined." |
14:10.23 | kergoth | but then i hit the .stop/.clear hang |
14:10.36 | foerster | they say just to remove the join |
14:10.48 | Crofton|work | hmm |
14:11.03 | Crofton|work | How do you control the order files are packaged in |
14:11.12 | kergoth | hmmm, so the server won't be joined until the UI process exits, still might have an issue though |
14:11.17 | kergoth | i'll test that, since i can reproduce |
14:11.24 | Crofton|work | I have some going into ${PN} but I want them in ${PN}-examples |
14:11.36 | kergoth | Crofton|work: add ${PN}-examples to PACKAGES before ${PN} |
14:11.39 | kergoth | use =+ instead of += |
14:11.49 | Crofton|work | ok |
14:11.54 | Crofton|work | I was thinking that |
14:12.06 | Crofton|work | the meaning is a ltittle funny |
14:12.14 | Crofton|work | since you would think "subtract" |
14:13.12 | kergoth | think of +=/=+ as more like list operations on a space separated list. |
14:13.18 | kergoth | -= would remove an element from that list |
14:13.51 | Crofton|work | urh |
14:13.53 | Crofton|work | I saw - |
14:14.23 | Crofton|work | that is cleare |
14:14.29 | Crofton|work | need 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.51 | foerster | kergoth_: we could try using a "Manager" - it says those queues aren't prone to such deadlocks |
14:21.35 | kergoth | foerster: huh, worth trying anyway |
14:22.13 | foerster | or, what if we have the server use cancel_join_thread()? |
14:37.47 | pb__ | hi kergoth |
14:38.22 | kergoth_ | hey pb__ |
14:42.47 | foerster | kergoth_: updated cache progress events https://github.com/foerster/bitbake/commit/ff086b864b60cf76e5c48cda4d42d59a0b027ccd |
14:43.00 | *** join/#oe jmpdelos (~polk@outgoing.delos.com) |
14:43.01 | foerster | seems to shave off most of the previous overhead |
14:44.26 | *** join/#oe GarthPS (~quassel@93.29.49.31) |
14:45.37 | kergoth_ | foerster: ah, nicely done |
14:45.50 | kergoth_ | tests cancel_join_thread |
14:46.34 | foerster | kergoth_: also, try putting a timeout in the join, and then inspecting the queue |
14:46.44 | foerster | maybe that will provide some insight |
14:47.48 | foerster | could call join in a loop with timeout to test |
14:48.45 | CIA-101 | 03Michael Smith <msmith@cbnco.com> 07master * r8e91420560 10openembedded.git/recipes/iproute2/ (3 files in 2 dirs): |
14:48.45 | CIA-101 | iproute2: upgrade to 2.6.35.1 |
14:48.45 | CIA-101 | Upgrade 2.6.35 to 2.6.35.1. The new version fixes "ip route get" and |
14:48.45 | CIA-101 | "ip addr flush". |
14:48.45 | CIA-101 | Signed-off-by: Michael Smith <msmith@cbnco.com> |
14:50.29 | kergoth_ | canceling the join of the event queue thread fixes it |
14:50.39 | kergoth_ | so we at least know for certain that that was the cause |
14:51.02 | foerster | sweet. Does not joining the queue thread cause any problems? |
14:51.08 | kergoth_ | no idea :) |
14:51.13 | foerster | hah |
14:51.20 | kergoth_ | i guess what it was trying to feed will never make it to the UI |
14:51.27 | foerster | well, only problem of concern is -- is it still running? |
14:51.34 | foerster | that thread get's wiped out still, I assume |
14:51.41 | kergoth_ | my pthreads-fu is weak |
14:51.43 | kergoth_ | i'd assume so |
14:52.07 | kergoth_ | 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.18 | foerster | right |
14:52.35 | foerster | alternatively, we could do the join loop with queue emptying |
14:52.43 | foerster | don't know if that would have any benefit or not |
14:52.48 | kergoth_ | yeah, don't know |
14:53.01 | kergoth_ | this is the thing that bugs me about multiprocessing. okay, it has all these classes that look nifty and all |
14:53.07 | kergoth_ | but there's a crapload of ways to do things |
14:53.18 | kergoth_ | where's the guidelines to tell me when to use which? :) |
14:53.19 | foerster | and not many good examples |
14:53.21 | kergoth_ | yeah |
14:53.53 | foerster | when it works though, it does make things quite nice |
14:53.59 | kergoth_ | 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.24 | kergoth_ | managers do look somewhat interesting in general though |
14:54.38 | foerster | yes, but if we only use the manager to provide a safe queue, it'd be different. |
14:54.50 | foerster | plus, the manager can be long lived, and clients could later connect to it |
14:54.54 | foerster | and use the same queues |
14:55.05 | kergoth_ | right |
14:55.08 | foerster | there's some api in there for connecting to the manager i believe |
14:55.25 | foerster | but, that's more of a drift from where we are now. cross such bridges if/when necessary |
14:55.31 | kergoth_ | right |
14:56.06 | foerster | did you have a chance to play with my ^C handling, or should I bring in the way you did it? |
14:56.19 | foerster | mine was dead simple, but seemed to work |
14:56.43 | foerster | i saw you also found a way to join the cache sync thread, right? |
14:57.47 | kergoth_ | 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.39 | kergoth_ | 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.59 | kergoth_ | so i think we may want to keep the sys.exit()s for the incomplete parses, or revamp those |
15:00.06 | kergoth_ | or add a new exception |
15:00.08 | foerster | ah, ok |
15:00.32 | kergoth_ | but, i'm still looking into it |
15:00.38 | kergoth_ | might be missing a cleaner method |
15:01.13 | kergoth_ | hrm |
15:01.45 | kergoth_ | 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.04 | kergoth_ | 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.20 | kergoth_ | since the state machine doesn't do an explicit A->B transition to check sanity or anything |
15:02.26 | kergoth_ | re-reads the code in question |
15:06.00 | foerster | yea, 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.44 | foerster | <PROTECTED> |
15:07.44 | foerster | <PROTECTED> |
15:07.45 | foerster | <PROTECTED> |
15:07.45 | foerster | <PROTECTED> |
15:07.45 | foerster | <PROTECTED> |
15:08.05 | kergoth_ | ouch |
15:08.17 | foerster | some funny business happening - we probably do need a better way to abort parsing |
15:09.27 | kergoth_ | yeah.. before buildTargets registers its idle function, it creates the runqueue and crap all based on our incomplete parse |
15:09.30 | kergoth_ | not good |
15:10.04 | foerster | sys.exit on any unclean parse shutdown? |
15:10.05 | *** join/#oe mickey|office (~Mickey@openmoko/coreteam/mickey) |
15:11.04 | kergoth_ | 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.22 | RP | kergoth: I like the idea of runqueue and crap :) |
15:19.36 | RP | kergoth: care to join the tsc channel for a second? |
15:19.52 | foerster | the ui probably needs to check for queue errors now so it can detect when the server exits, no? |
15:21.36 | kergoth_ | chuckles |
15:22.28 | kergoth_ | foerster: no, the systemexit gets caught by the code that's handling teh command, and raises CookerCommandFailed in the finishAsyncCommand or whatever |
15:22.58 | foerster | kergoth_: awesome, even better. |
15:23.43 | *** part/#oe mrj10 (~mrj10@mjlap.crhc.uiuc.edu) |
15:29.26 | Crofton|work | I think I am having the issue where cleaning a task does not really clean it |
15:29.30 | Crofton|work | does that ruing a bell? |
15:32.59 | kergoth_ | 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.29 | kergoth_ | 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.11 | kergoth_ | but i think its slightly cleaner than the finalize() bits |
15:36.24 | foerster | cool. I'll bring your changes in. |
15:37.09 | kergoth_ | 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.08 | foerster | kergoth_: 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.33 | foerster | but not sure what else to do - it helps get rid of some ^C stack traces when the user tries to abuse us |
15:43.35 | kergoth_ | thats not theoretical |
15:43.43 | kergoth_ | i kept having to kill bitbake debugging this issue ;) |
15:43.50 | foerster | right |
15:44.16 | foerster | i thought maybe to block it, then join with a few second timeout or something |
15:44.42 | kergoth_ | what's the danger if that bit isn't there? |
15:44.55 | kergoth_ | should we just catch keyboardinterrupt and forcibly terminate the server if we have to? |
15:44.55 | foerster | just extra uncaught ^c exceptions |
15:44.59 | kergoth_ | nods |
15:45.23 | foerster | that would probably work too |
15:47.17 | kergoth_ | i guess the higher up you are when you catch keyboard interrupt, the better |
15:47.32 | foerster | without catching, you'd get a stack track showing server.join |
15:47.32 | foerster | other than that, everything is looking good here so far |
15:47.43 | foerster | wait, that's odd. I'm always getting ERROR: Command execution failed: Exited with 1 | ETA: --:--:-- |
15:47.49 | kergoth_ | hmmm |
15:47.54 | kergoth_ | strange |
15:48.01 | foerster | cache loads, parsing doesn't happen |
15:48.02 | foerster | wtf |
15:48.28 | kergoth_ | bisect my changes? :) |
15:48.34 | foerster | any attempt at parsing and it bails |
15:48.41 | foerster | yea, let me try |
15:49.54 | kergoth_ | 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.53 | foerster | hmm. resurrect sys.exit usage causes me breakage |
15:52.46 | foerster | commit ebdf3db3b612c1d56c8a71adb8bdffb327ca9582 |
15:53.21 | kergoth_ | hmm, well, maybe we should revisit the interrupted parsing for a build issue then |
15:53.44 | foerster | it's not even getting into parsing here |
15:53.50 | foerster | no interrupts at all |
15:53.51 | foerster | :) |
15:54.27 | kergoth_ | what i mean is, drop that commit for now and revisit the issue it fixed later, since it clearly causes other problems |
15:55.52 | foerster | curious what the hell it's doing though |
15:57.13 | kergoth_ | agreed |
15:57.22 | foerster | it's bailing in updateCache |
15:57.29 | kergoth_ | considering those should only be hit when shutting down |
15:57.34 | foerster | why is state shutdown or stop there when parsing? |
15:57.35 | foerster | right |
15:57.36 | kergoth_ | i don't see how it could happen in a normal run |
15:57.37 | kergoth_ | right |
15:58.03 | khem | ericben|away: thanks |
15:58.24 | khem | eFfeM_work: did the gcc patch I gave helped your case ? |
15:58.27 | khem | gm all |
15:59.29 | foerster | kergoth_: should have been cookerAction, not cookerState I believe |
15:59.35 | foerster | state is (clean, parsing, parsed) |
15:59.41 | *** join/#oe dth_ntb (~dth@a89-183-4-63.net-htp.de) |
16:00.05 | kergoth_ | oh, yes, that's my fault |
16:00.08 | kergoth_ | master merged the two :) |
16:00.11 | foerster | ah |
16:00.14 | kergoth_ | maybe we should get that rebase done :) |
16:00.15 | *** part/#oe dth_ntb (~dth@a89-183-4-63.net-htp.de) |
16:00.40 | foerster | probably wise |
16:00.49 | khem | http://lwn.net/Distributions/#embed |
16:00.54 | kergoth_ | its just state - initial, parsing, running, shutdown, stop now |
16:00.59 | kergoth_ | which i think is much less confusing |
16:01.00 | khem | search for 'OpenEmbedded' |
16:01.08 | foerster | kergoth_: agreed |
16:01.14 | khem | release is mentioned |
16:01.23 | kergoth_ | khem: nice |
16:01.44 | khem | I pinged Jonathan to add it |
16:02.41 | ericben | hi khem |
16:03.38 | khem | hi |
16:03.47 | ericben | while 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.15 | khem | hmm |
16:04.16 | ericben | which is not a good thing ... |
16:04.27 | khem | right |
16:04.56 | ericben | I have a patch for this : I do a chmod -R go-w before doing thez fakeroot tar in meta-toolchain.bb |
16:05.03 | ericben | is that an acceptable fix ? |
16:08.09 | khem | ericben: sounds ok to me. Send to ml |
16:08.46 | khem | I think we should update news section more often with OE dev news |
16:08.55 | khem | however small it is |
16:09.25 | ericben | khem: 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.30 | khem | I dont |
16:12.23 | ericben | concerning local generation with qemu : it seems qemu 0.13 hangs for ever when building into a virtualmachine run by virtualbox |
16:12.38 | ericben | switching back to 0.12.5 works |
16:13.23 | JaMa | for me (no virtualbox) it seems to build much longer, but it finishes ok in the end |
16:13.25 | ericben | khem: are you aware of big changes in qemu's configuration or code which could explain this ? |
16:13.37 | ericben | JaMa: I did wait about 6 hours ! |
16:14.00 | foerster | kergoth_: rebased onto master |
16:14.39 | foerster | https://github.com/foerster/bitbake/commits/separate-ui-and-server |
16:14.41 | khem | ericben: hmmm, I just saw that it fixed a crash |
16:15.22 | khem | ericben: I think I will add the cross locale generation to eglibc |
16:15.26 | ericben | khem: I can reproduce this 100% case until now (on different host either linux or windows as the native os) |
16:15.36 | khem | and get rid of qemu |
16:16.01 | khem | ericben: ok reinstate 0.12.5 if you like |
16:16.40 | JaMa | ericben: here it's about 50min, while normally (qemu-kvm in gentoo box) it's in about 10min |
16:17.22 | JaMa | ericben: but for gentoo I'm not building all targets.. |
16:24.46 | kergoth_ | 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.50 | kergoth_ | quite strange |
16:24.55 | kergoth_ | might have to try to get ahold of the upstream |
16:25.06 | kergoth_ | 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.36 | foerster | kergoth_: yea, seems odd |
16:30.37 | fidencio | JaMa: Hey! |
16:31.05 | fidencio | JaMa: we have a serious problem with hours hehehe |
16:31.41 | JaMa | fidencio: hey |
16:31.53 | kergoth_ | hmm |
16:32.26 | fidencio | JaMa: a question. How you compile EFL with debug support? Are you using task-efl-x11-core (or something like this |
16:32.29 | fidencio | )? |
16:32.34 | foerster | kergoth_: http://mail.python.org/pipermail/python-list/2009-March/1196649.html we're not the only ones confused |
16:32.54 | kergoth_ | huh, indeed |
16:33.04 | kergoth_ | tries a minimal test case |
16:33.40 | JaMa | fidencio: without debug |
16:33.59 | fidencio | JaMa: '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.31 | fidencio | JaMa: and EFL are segfaulting here. I think that is a stupid problem with efreet and freescale hardware |
16:34.41 | JaMa | fidencio: and task-x11-illume |
16:35.52 | JaMa | fidencio: #DEBUG_BUILD = "1" |
16:35.53 | JaMa | #PACKAGE_STRIP = "no" |
16:36.09 | JaMa | to your local.conf (without #) and bump EFL_SRCREV to force rebuild :) |
16:36.22 | kergoth_ | 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.25 | kergoth_ | shakes head |
16:36.35 | fidencio | JaMa: Yeap. I do it. |
16:36.53 | foerster | surely, there must be some reason :) |
16:36.57 | fidencio | But I need to create my image with *-dbg packages |
16:36.58 | kergoth_ | so, anyone know if git submodule stopped sucking? |
16:37.05 | kergoth_ | or if its best to use alternatives like braid? |
16:37.10 | kergoth_ | or mr, or.. |
16:37.16 | fidencio | JaMa: the packages were created |
16:37.19 | JaMa | fidencio: -dbg packages are built by default |
16:37.33 | JaMa | fidencio: you can opkg install those on target |
16:37.37 | kergoth_ | fidencio: IMAGE_FEATURES += "dbg" will add all -dbg packages to any image you build |
16:38.00 | JaMa | also with ~200MB eglibc-dbg :/ |
16:38.05 | kergoth_ | hehe |
16:38.12 | kergoth_ | maybe it needs a blacklist :) |
16:38.13 | fidencio | kergoth_: but it fails because there's packages that -dbg were not createad |
16:38.15 | JaMa | khem: any idea why is eglibc-dbg so big nowadays? |
16:38.21 | kergoth_ | fidencio: then those packages should get fixed :) |
16:38.33 | JaMa | khem: or can we split eglibc-dbg ie to eglibc-static-dbg? |
16:38.41 | fidencio | kergoth_: nhaaaaaaam. hehehee. ok. I'll try again and will send patches |
16:38.44 | kergoth_ | hehe |
16:39.02 | kergoth_ | as JaMa said, can always install them manually, but might be faster to fix the recipes with no -dbgs :) |
16:40.16 | fidencio | kergoth_: bitch. I was looking for a lazy way. heheeh |
16:40.34 | JaMa | fidencio: iirc you work for profusion, right? do you work on webkit-efl too? |
16:41.22 | fidencio | JaMa: nops. But antognolli, k-s, jprvita, demarchi and acidx (@ #edevelop) can help you :-) |
16:43.21 | JaMa | ok thanks |
16:44.55 | fidencio | JaMa: you're welcome! |
16:45.14 | kergoth_ | 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.34 | fidencio | kergoth_: /me too |
16:45.38 | fidencio | bbl |
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.33 | kergoth_ | hmm, my u-boot-fu is rusty, i should look for a guide for getting something useful on my sheevaplug |
16:49.16 | JaMa | kergoth_: which gcc version are you using for u-boot builds? |
16:49.27 | kergoth_ | none yet :) |
16:50.03 | JaMa | kergoth_: 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.09 | kergoth_ | ah |
16:50.12 | kergoth_ | interesting |
16:50.52 | JaMa | so better to practise your -fu somewhere safe :) |
16:51.08 | foerster | i 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.29 | kergoth_ | 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.43 | kergoth_ | or, maybe could do something with patchwork for that and archive all patches in gmail :) |
16:52.00 | kergoth_ | notices he has to mute a *lot* of patch threads in the oe ml for things he doesn't care about |
16:52.57 | JaMa | is just deletes the patches and threads which doesn't touch anything I ever use and keeping whole history only in gmail folder |
16:53.26 | kergoth_ | i guess auto-archiving all patch threads to mailing lists could make sense, with a saved search to look at them explicitly |
16:53.41 | kergoth_ | since i use my inbox as things that require action, 90% of the patches don't, so.. |
16:53.42 | kergoth_ | 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.11 | pb_ | kergoth: yah, that sounds like an area where patchwork might be useful. |
17:23.22 | pb_ | can't think of any way to do it with straightforward MUA filters. |
17:28.40 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * rddd56fb6cb 10openembedded.git/recipes/linux/linux-omap-hah_2.6.31.bb: |
17:28.40 | CIA-101 | linux-omap-hah: remove unused variable CVS_TARBALL_STASH |
17:28.40 | CIA-101 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
17:28.40 | CIA-101 | Acked-by: Stefan Schmidt <stefan@datenfreihafen.org> |
17:30.16 | kergoth_ | yeah, really need to be able to inspect the patches themselves, run lsdiff from patchutils, whatever |
17:30.40 | pb_ | right |
17:31.04 | pb_ | 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.19 | kergoth_ | nods |
17:31.24 | kergoth_ | i don't exactly use procmail anymore ;) |
17:31.36 | pb_ | heh |
17:31.55 | kergoth_ | i think my work mail server might support sieve, but i don't think it has the very useful plugins for it |
17:31.59 | kergoth_ | ah well |
17:39.29 | *** join/#oe woglinde (~heinold@f052064024.adsl.alicedsl.de) |
17:41.06 | cbrake | unpacks panda board |
17:41.10 | kergoth_ | nice |
17:42.22 | woglinde | hi kergoth and cbrake |
17:42.30 | fidencio | cbrake: I'll get mine in the next week :-) |
17:43.44 | kergoth_ | hey woglinde |
17:44.51 | cbrake | woglinde: hello |
17:46.37 | kergoth_ | 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.03 | foerster | sweet |
17:47.19 | foerster | gotta jet, dentist appointment. see ya for now |
17:47.21 | kergoth_ | considering xmlrpc used to be *slower*.. |
17:47.23 | kergoth_ | 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.00 | eFfeM | gm |
18:01.05 | kergoth_ | hey eFfeM |
18:01.19 | eFfeM | kergoth_ Hi! |
18:02.03 | *** join/#oe marex (~marex@eduroam6.ms.mff.cuni.cz) |
18:02.04 | eFfeM | khem, 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.26 | CIA-101 | 03Philip Balister <philip@balister.org> 07org.openembedded.dev * r604fe17b54 10openembedded.git/recipes/autoconf/autoconf.inc: |
18:08.26 | CIA-101 | Revert "autoconf.inc: Use 'which' to find m4" |
18:08.26 | CIA-101 | This reverts commit 8da17586c547f365ae667eb2608ba89a1c375afc. |
18:08.26 | CIA-101 | This commit broke autoconf running on the target. I spoke with Tom Rini and he |
18:08.26 | CIA-101 | approved the revert of his commit. |
18:08.36 | CIA-101 | 03Philip Balister <philip@balister.org> 07org.openembedded.dev * r5f62651cbf 10openembedded.git/recipes/uhd/uhd.inc: uhd : Fix packaging for examples and test programs. |
18:13.44 | Crofton|work | khem, can you commit the fix you made for me yesterday? |
18:13.49 | Crofton|work | it 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.30 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * rc1d9a905c2 10openembedded.git/recipes/openssl/openssl.inc: |
18:31.30 | CIA-101 | openssl: allow to add configure options through EXTRA_OECONF |
18:31.30 | CIA-101 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
18:31.30 | CIA-101 | Acked-by: Michael Smith <msmith@cbnco.com> |
18:31.49 | *** part/#oe mrj10 (~mrj10@63.252.64.254) |
18:32.42 | woglinde | hms |
18:32.52 | woglinde | no rw for obi yet? |
18:33.35 | *** join/#oe hansdampf (~moritz@212.77.182.171) |
18:33.54 | obi | woglinde: i just pushed my second commit ;) |
18:38.50 | woglinde | fine |
18:41.02 | CMoH | hmm... bitbake from git is a total mistery; nothing that worked still works |
18:41.15 | kergoth_ | CMoH: what do you mean? |
18:41.31 | CMoH | well, there's no more bitbake -i |
18:41.45 | kergoth_ | 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.16 | kergoth_ | 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.20 | CMoH | i see; well i just moved from my setup based on 1.8.18 to this git master |
18:42.38 | CMoH | 1.11.0 |
18:42.41 | kergoth_ | that would be a massive change, yes. the master branch was separated from 1.8 2 years before 1.10 finally released. |
18:43.03 | CMoH | still it seems ubuntu and gentoo (also your openembedded manual) are all based on 1.8 |
18:43.48 | kergoth_ | OE doesn't require 1.10 yet. |
18:43.53 | kergoth_ | so that's not too surprising |
18:44.11 | kergoth_ | did you have an issue other than -i? |
18:44.12 | CMoH | yeah... humpf... and there are no layers or bbappend recipes in 1.8 |
18:44.28 | kergoth_ | that's not quite correct, they're just available in a different way |
18:44.37 | khem | Crofton|work: Can I add your Tested-by |
18:44.46 | Crofton|work | please do |
18:44.55 | kergoth_ | 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.56 | CMoH | kergoth_, i'm very interested in what you mean |
18:45.06 | CMoH | i see |
18:45.12 | kergoth_ | do a bit of googling for those, you'll find the instructions |
18:45.34 | khem | obi should send keys to cbrake or me |
18:45.34 | CMoH | so what's the direction you'd recommend? |
18:45.34 | kergoth_ | er, sorry, its still collections.inc, not collections.bbclass. |
18:45.35 | kergoth_ | use 1.10 or master and deal with the lack of -i. |
18:45.38 | kergoth_ | would be my advice. |
18:45.47 | CMoH | ah, that's the least of my problems :) |
18:45.48 | kergoth_ | we're likely releasing 1.11 in the next few weeks |
18:45.57 | kergoth_ | well, we can't fix problems without reports. |
18:46.01 | kergoth_ | i haven't heard of any outstanding issues |
18:46.11 | kergoth_ | there are a grand total of 2 people working on bitbake |
18:46.21 | CMoH | ah, i'd better read the manual - first i wanted a confirmation that it's been really changed |
18:46.23 | kergoth_ | well, 3 now |
18:46.31 | CMoH | great job! |
18:46.54 | kergoth_ | i don't mind helping, if you're having trouble, just ask |
18:47.19 | CMoH | thanks - i will; though usually i try to find some docs first |
18:47.36 | kergoth_ | you won't find much ;) |
18:47.42 | kergoth_ | there's the OE manual, but beyond that.. |
18:47.50 | kergoth_ | the bitbake documentation is weak at best |
18:48.46 | CMoH | well my first shock was ERROR: Nothing to do. Use 'bitbake world' to build everything |
18:49.06 | CMoH | as far as i knew, i'd have to provide a package - where's the world thing coming from? |
18:49.23 | eFfeM | khem any new clue on the mediatomb issue ? |
18:49.28 | kergoth_ | what exactly was the bitbake command you ran? |
18:49.44 | kergoth_ | that error will only happen if 1) your BBFILES isn't correct, or 2) you didn't specify a package |
18:49.44 | CIA-101 | 03Roman 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.45 | CIA-101 | at 3.1.12: fix parallel make fix |
18:49.45 | CIA-101 | Use dummy target to avoid race with double yacc invocation. |
18:49.45 | CIA-101 | Signed-off-by: Roman I Khimov <khimov@altell.ru> |
18:49.48 | CMoH | just bitbake |
18:49.55 | CMoH | true |
18:49.55 | kergoth_ | well, what do you expect? |
18:50.02 | kergoth_ | bitbake doesn't read your mind to know what you want to build |
18:50.09 | CMoH | lol, no |
18:50.23 | CMoH | is there any "world" recipe ? |
18:50.41 | CMoH | like my portage world file |
18:51.10 | *** join/#oe Heinervdm (~thomas@pD9E160FD.dip.t-dialin.net) |
18:51.12 | Jay7 | world is reserved word :) |
18:52.56 | khem | eFfeM: is this recipe upstream ? |
18:53.01 | eFfeM | khem, yes |
18:53.41 | kergoth_ | world is magic |
18:53.47 | CMoH | what does it do? |
18:53.54 | khem | let me try to reproduce it. If you are lucky I will reproduce it |
18:53.55 | kergoth_ | it builds every provider, unless that provider is provided by multiple recipes, in which case it builds the preferred one |
18:54.03 | eFfeM | khem: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/mediatomb/mediatomb_0.11.0.bb |
18:54.07 | kergoth_ | so it builds everything, but for e.g. virtual/kernel, it only builds the preferred kernel |
18:54.16 | CMoH | i see |
18:54.20 | kergoth_ | remember that bitbake was based on portage originally, so world *should* seem familiar to you |
18:54.30 | CMoH | :) |
18:54.45 | eFfeM | khem, thanks (it is configure to find js), btw I compiled for armv5te (sheevaplug), distro minimal |
18:54.50 | kergoth_ | also, this behavior was the same in 1.8. you hvae to specify a package to build, and world builds everything |
18:55.03 | kergoth_ | but remember that OE has, what, nearly 8,000 recipes or something now -- you *really* don't want to build world |
18:55.20 | kergoth_ | 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.20 | CMoH | well... my current real problem is bitbake console-image does nothing |
18:55.25 | kergoth_ | what do you mean? |
18:55.40 | kergoth_ | 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.50 | CMoH | nothing at all |
18:55.54 | CMoH | i get a new prompt |
18:56.02 | khem | eFfeM: as long as arch is arm it should be reproducable |
18:56.03 | kergoth_ | interesting |
18:56.06 | kergoth_ | try 1.10. |
18:56.14 | kergoth_ | git checkout -b 1.10 origin/1.10 |
18:56.16 | kergoth_ | in the git repo |
18:56.18 | CMoH | bitbake -D console-image the same |
18:56.19 | kergoth_ | then run it again |
18:56.27 | eFfeM | khem, will try to create a small usecase using the code generated by configure |
18:56.32 | CMoH | kk |
18:56.38 | kergoth_ | its likely that the error is occurring too early on, before the UI exists to display the error, a bug in bitbake |
18:56.47 | kergoth_ | with 1.10 you're certain to see it, or nearly so |
18:56.49 | CIA-101 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r4537344b82 10openembedded.git/recipes/initrdscripts/initramfs-uniboot_1.0.bb: |
18:56.50 | CIA-101 | initrdscripts/initramfs-uniboot_1.0.bb: DESCRIPTON -> DESCRIPTION |
18:56.50 | CIA-101 | (saw this on the poky ML) |
18:56.50 | CIA-101 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
18:57.00 | CIA-101 | 03Frans 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.06 | khem | eFfeM: 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.49 | khem | eFfeM: its good to do git log before pushing |
18:57.54 | eFfeM | khem, would that help? anyway it seems worth trying |
18:58.37 | CMoH | kergoth_, what is each of the UIs good for? |
18:58.51 | CMoH | ncurses/depexp (which seems to like -g)/knotty |
18:59.05 | kergoth_ | knotty is the default UI, the commandline, noninteractive one |
18:59.15 | eFfeM | khem, 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.24 | eFfeM | afk for a while |
18:59.31 | kergoth_ | 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.33 | CMoH | i.e. the one you get when building a package off command-line or running other commands, |
18:59.45 | kergoth_ | bitbake foo -> runs knotty |
19:00.35 | *** join/#oe kevinsc1 (~a0214685@nat/ti/x-aprhdplwfxjlsqzl) |
19:01.09 | CMoH | i'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.21 | Crofton|work | If I run configure on the target, what does it use for CFLAGS? |
19:02.34 | CIA-101 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * rd1f84edcb2 10openembedded.git/recipes/webkit/ (4 files in 2 dirs): |
19:02.34 | CIA-101 | webkit-efl: bump SRCREV and add patch for scrolling issue |
19:02.34 | CIA-101 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
19:06.32 | kergoth_ | CMoH: knotty is the only one that's getting attention right now. |
19:06.42 | kergoth_ | though the poky/yocto folks have done some work on goggle recently |
19:06.53 | kergoth_ | so i take that back, but its still the primary |
19:07.20 | kergoth_ | 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.59 | CMoH | yeah, before i handed it a package to build |
19:17.35 | CMoH | hmmm - it seems to work with 1.10.1 |
19:17.45 | CMoH | err 1.10.0 |
19:18.56 | *** join/#oe dijenerate (~dijenerat@65.48.156.82) |
19:21.49 | CMoH | i guess i'll see the results in 2-3 hours :( |
19:23.23 | CMoH | it's much faster than 1.8 though with runqueue and these things |
19:24.05 | kergoth_ | 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.47 | CIA-101 | 03Khem Raj <raj.khem@gmail.com> 07master * rc1facf79a2 10openembedded.git/recipes/js/js_1.5.bb: |
19:31.47 | CIA-101 | js_1.5.bb: Beat it to respect LDFLAGS |
19:31.47 | CIA-101 | * Fixes QA errors like below |
19:31.47 | CIA-101 | ERROR: QA Issue with js: No GNU_HASH in the elf binary: |
19:31.47 | CIA-101 | '/scratch/oe/work/armv7a-oe-linux-gnueabi/js-1.5-r2/packages-split/js/usr/lib/libjs.so' |
19:32.13 | khem | eFfeM: hmmm I have libtool 2.4 and mediatomb needs to update libtool macros I think |
19:32.20 | khem | so I get bitten |
19:33.15 | Crofton|work | khem, I have another issue |
19:33.26 | Crofton|work | <PROTECTED> |
19:33.30 | Crofton|work | leads to failiure |
19:33.32 | Crofton|work | on target |
19:34.06 | Crofton|work | http://pastebin.com/2t6QAkBJ |
19:35.09 | khem | eFfeM: http://pastebin.com/kBLMTUxn |
19:35.33 | khem | Crofton|work: thats wrong usage for OE armv7/gcc |
19:35.45 | khem | we dont support hard float abi |
19:35.47 | khem | yet |
19:35.50 | Crofton|work | what is the right usage |
19:35.52 | khem | I want to fo that |
19:36.19 | khem | just gcc -v -o hello hello.c should select correct float abi |
19:36.36 | khem | -mfloat-abi=softfp |
19:36.42 | khem | is the one you should use |
19:38.08 | Crofton|work | hmm |
19:38.16 | Crofton|work | I need to figure out why I am confused |
19:39.08 | khem | there are two things one is presense of FP hardware itself second is using FP registers in ABI to pass function arguments |
19:39.17 | Crofton|work | yeah |
19:39.29 | khem | so you have two params |
19:39.37 | CMoH | kergoth_, unfortunately i don't have the time to learn how to debug it in order to get you a good bug report |
19:39.38 | Crofton|work | ok, there is code in tune-cortexa8 to switch it |
19:39.43 | khem | -mfpu and -mfloat-abi |
19:39.45 | Crofton|work | but iti is still using softfp |
19:39.49 | kergoth_ | CMoH: np, hopefully i'll run into it at some point |
19:39.51 | CMoH | but if you assist me i'd be willing to do it |
19:40.11 | khem | mfpu tells the compiler that you can use fpu for generating code |
19:40.16 | kergoth_ | i'm not sure how without sprinkling prints in the code :) |
19:40.27 | ashen | hi, 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.38 | khem | -mfloat-abi tells it that you should use FP registers according to ABI when passing params to functions |
19:40.44 | Crofton|work | yeah |
19:40.48 | ashen | as i really not care a about ipkg is there a way ho to disable building it? or build opkg instead? |
19:40.52 | Crofton|work | I have some understanding of the differences :) |
19:41.01 | kergoth_ | it isn't fetching ipkg, its fetching ipkg-utils, most likely |
19:41.05 | kergoth_ | we don't build ipkg anymore |
19:41.08 | khem | -mfloat-abi=softfp says that calling conventions do not use FP regs |
19:41.11 | ashen | yeah ipkg-utils, sorry |
19:41.12 | CMoH | kergoth_, is it possible to run bitbake from within the git repo? i mean without installing it into /usr etc |
19:41.23 | Crofton|work | CMoH, yes |
19:41.35 | Crofton|work | just set your path to the git repo bitbake/bin I thinnk |
19:41.38 | Crofton|work | I do that |
19:42.01 | kergoth_ | yep |
19:42.13 | kergoth_ | at one time that was the only way to run it ;) |
19:42.28 | Crofton|work | only crazy people install bitbake |
19:42.33 | kergoth_ | hehe |
19:42.34 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
19:42.46 | CMoH | lol |
19:43.06 | kergoth_ | 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.09 | CMoH | i'd also ask you on how to make a .deb off it (i'm not familiar with ubuntu but...) |
19:43.39 | kergoth_ | the debian metadata isn't maintained upstream, the debian folks do it |
19:43.53 | kergoth_ | you'd have to copy the debian dir from their source package and modify it to create a package for 1.10 |
19:45.07 | CMoH | i see - thanks |
19:49.06 | ashen | so how can i get rid of ipkg-utils? |
19:51.03 | kergoth_ | you don't. its required to build opkg-based root filesystems |
19:51.12 | kergoth_ | the tarball is available on our mirrors, as far as i know |
19:51.19 | ka6sox | the native is |
19:51.21 | kergoth_ | 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.35 | CMoH | yup |
19:54.44 | CMoH | the problem is in setup.py it seems |
19:54.59 | CMoH | i've updated bitbake-9999.ebuild to use the git repo |
19:55.28 | CMoH | now running it directly from the git repository it works; installing it via the ebuild produces an unusable bitbake |
19:56.20 | kergoth_ | what's the behavior? |
19:56.33 | CMoH | it does nothing |
19:56.52 | kergoth_ | gah, we haven't killed those prints of unpackaged files, particularly in the kernel, yet? |
19:56.58 | kergoth_ | this is agonizingly slow |
19:57.48 | *** join/#oe GNUtoo|laptop (~gnutoo@50.118-226-89.dsl.completel.net) |
20:00.56 | ashen | kergoth_ thanks, so if I download it manually and put it in sources it bypass the do_fetch task? |
20:01.19 | kergoth_ | 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.24 | ashen | kergoth_: 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.39 | GNUtoo|laptop | Applying patch fix-ecore-fb-initialization.patch fails... |
20:34.42 | GNUtoo|laptop | is it normal? |
20:35.17 | GNUtoo|laptop | is 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.55 | eFfeM | khem, 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.02 | eFfeM | thanks 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.16 | kergoth_ | decides to temporarily use github for the bitbake todo - https://github.com/kergoth/bitbake/wiki/TODO |
20:52.06 | foerster | kergoth_: looks good enough there |
20:52.19 | foerster | none 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.04 | kergoth_ | cool, that's a good idea |
20:53.36 | foerster | they all must be quite old - all reference MsgBase and puke, and event.sofar for ParseProgress |
20:53.51 | kergoth_ | nods |
20:54.01 | kergoth_ | current master has some updates for goggle from poky for some of that |
20:54.06 | foerster | ok |
20:54.10 | foerster | i was just playing with goggle |
20:54.15 | foerster | perhaps i need to look at what they did |
20:55.59 | kergoth_ | cute, i like that github backs their wikis with git |
20:56.12 | Jay7 | have described how kexecboot works on kexecboot.org |
20:56.57 | Jay7 | I need some native english speaker to fix texts there :) |
20:57.04 | CIA-101 | 03Eric Bénard <eric@eukrea.com> 07org.openembedded.dev * r8c56bc9a03 10openembedded.git/recipes/meta/meta-toolchain.bb: (log message trimmed) |
20:57.04 | CIA-101 | meta-toolchain: fix directories rights |
20:57.04 | CIA-101 | Actual sdk change rights of /usr and /usr/local to 775 when |
20:57.04 | CIA-101 | untaring the archives with sudo ... giving group write access |
20:57.04 | CIA-101 | to these directories. |
20:57.13 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * ra5781edff2 10openembedded.git/recipes/opensync/msynctool_0.22.bb: |
20:57.13 | CIA-101 | msynctool_0.22: fixed SRC_URI |
20:57.13 | CIA-101 | Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de> |
20:57.13 | CIA-101 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
20:57.18 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r157adffd31 10openembedded.git/recipes/asterisk/asterisk_1.2.24.bb: (log message trimmed) |
20:57.18 | CIA-101 | asterisk_1.2.24: Set correct Checksum |
20:57.18 | CIA-101 | Tilghman Lesher <tlesher@digium.com> wrote on asterisk-users@lists.digium.com: |
20:57.18 | CIA-101 | Due to a licensing issue with some of the files we distributed with previous |
20:57.18 | CIA-101 | tarballs, we removed those files from archived tarballs in order to avoid |
20:57.26 | CIA-101 | u2nl_1.3: fixed SRC_URI |
20:57.26 | CIA-101 | new version avalible. |
20:57.27 | CIA-101 | Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de> |
20:57.27 | CIA-101 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
20:57.28 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r21747e1784 10openembedded.git/recipes/redfang/redfang.bb: |
20:57.28 | CIA-101 | redfang: fixed SRC_URI |
20:57.29 | CIA-101 | Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de> |
20:57.36 | CIA-101 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
20:57.36 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r2a53e4713e 10openembedded.git/recipes/dasher/dasher-gpe_0.0-svn.bb: |
20:57.37 | CIA-101 | dasher-gpe_0.0-svn: fixed SRC_URI |
20:57.37 | CIA-101 | Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de> |
20:57.43 | foerster | and goggle is broken afaik, even with their changes |
20:57.46 | CIA-101 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
20:57.46 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r5a0067a970 10openembedded.git/recipes/esc/esc-gst_6.bb: |
20:57.46 | CIA-101 | esc-gst_6: fixed SRC_URI |
20:57.46 | CIA-101 | Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de> |
20:57.46 | CIA-101 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
20:57.47 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r75abfabf5b 10openembedded.git/recipes/gtk2-ssh-askpass/gtk2-ssh-askpass_0.3.bb: |
20:57.47 | CIA-101 | gtk2-ssh-askpass_0.3: fixed SRC_URI |
20:57.55 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * r038f37dc6c 10openembedded.git/recipes/litestream/litestream_1.3RC3.bb: |
20:57.55 | CIA-101 | litestream_1.3RC3: fixed SRC_URI |
20:57.56 | CIA-101 | Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de> |
20:57.57 | CIA-101 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
20:57.57 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * rebf2b36c38 10openembedded.git/recipes/mathomatic/mathomatic_12.4.2.bb: |
20:57.58 | CIA-101 | mathomatic_12.4.2: fixed SRC_URI |
20:57.58 | CIA-101 | Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de> |
20:57.59 | CIA-101 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
20:57.59 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * re4d21b8c78 10openembedded.git/recipes/esc/esc-media_5.bb: |
20:58.07 | CIA-101 | Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de> |
20:58.07 | CIA-101 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
20:58.08 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * rc8c00df694 10openembedded.git/recipes/maxima/maxima_5.21.1.bb: |
20:58.08 | CIA-101 | maxima_5.21.1: fixed SRC_URI |
20:58.09 | CIA-101 | Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de> |
20:58.10 | CIA-101 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
20:58.10 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * rfb73531e5c 10openembedded.git/recipes/scsi-idle/scsi-idle_2.4.23.bb: |
20:58.11 | CIA-101 | scsi-idle_2.4.23: fixed SRC_URI |
20:58.11 | CIA-101 | Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de> |
20:58.18 | CIA-101 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
20:58.18 | CIA-101 | 03Klaus Schwarzkopf <schwarzkopf@sensortherm.de> 07org.openembedded.dev * rff004eb674 10openembedded.git/recipes/sidplay-base/sidplay-base_1.0.9.bb: |
20:58.18 | CIA-101 | sidplay-base_1.0.9: fixed SRC:URI |
20:58.18 | CIA-101 | Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de> |
20:58.18 | CIA-101 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
20:59.10 | foerster | kergoth_: the recent changes to goggle don't make it work in master, so I don't know what they were doing :) |
20:59.39 | foerster | in fact, the main culprit is RunningBuild, which references outdated event types |
20:59.58 | kergoth_ | 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.04 | foerster | ah |
21:00.07 | foerster | i'm on it |
21:00.09 | kergoth_ | :) |
21:00.21 | foerster | is having fun not working on work stuff today |
21:00.33 | ericben | kergoth_: foerster: what do you call ui when talking of bitbake ? (maybe stupid question sorry) |
21:00.51 | kergoth_ | ericben: master supports multiple user interfaces. |
21:01.04 | foerster | kergoth_: not really :) |
21:01.08 | kergoth_ | the default commandline one, as well as an X11 dependency explorer, a broken ncurses interface, etc |
21:01.09 | foerster | it's supposed to, but doesn't |
21:01.12 | kergoth_ | well, in theory, it should |
21:01.14 | kergoth_ | yeah :) |
21:01.38 | ericben | kergoth_: ah ok. How can I try this ? |
21:01.38 | foerster | i'm going to fix up RunningBuild now to fix some of the problems |
21:01.47 | kergoth_ | 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.03 | kergoth_ | some of bitbake's commandline options make no sense for some UIs |
21:02.30 | ericben | ok bitbake -u things in lib/bb/ui |
21:02.38 | foerster | ericben: yes |
21:03.32 | kergoth_ | 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.33 | foerster | well, we'll see if we can easily fix any of them |
21:04.37 | kergoth_ | 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.46 | kergoth_ | nods |
21:05.11 | foerster | easiest way is to remove -u from options for now |
21:05.22 | kergoth_ | that's true |
21:05.36 | foerster | or, only list knotty |
21:05.51 | foerster | if someone wants to run another, they can still specify it directly |
21:05.56 | kergoth_ | thats probably best, as we know from -i, user's really dislike commandline options vanishing :) |
21:06.04 | kergoth_ | s/'s/s/ |
21:06.33 | foerster | yea, i see references to -i, but in docs and everything, but found that it doesn't exist |
21:07.20 | kergoth_ | 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.28 | kergoth_ | (later on) |
21:07.48 | foerster | yes. |
21:08.03 | *** join/#oe mrj10 (~mrj10@63.252.64.254) |
21:08.22 | kergoth_ | 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.13 | GNUtoo|laptop | is ecore broken? |
21:10.45 | GNUtoo|laptop | or is it me(computer battery finished in the middle of a build) |
21:10.56 | GNUtoo|laptop | Applying patch fix-ecore-fb-initialization.patch fails... |
21:11.31 | ericben | GNUtoo|laptop: hi, what is the name of the recipe (I can try it now) |
21:11.48 | GNUtoo|laptop | else I can try to fix |
21:11.50 | GNUtoo|laptop | ecore_svn |
21:11.53 | GNUtoo|laptop | and look into it |
21:12.00 | GNUtoo|laptop | just that I had other stuff to do |
21:12.04 | GNUtoo|laptop | such as going to bed |
21:12.07 | GNUtoo|laptop | (tired) |
21:12.47 | GNUtoo|laptop | hi btw |
21:16.03 | ericben | cool pandaboard should ship in 3 days only 3 weeks late not bad |
21:17.10 | ericben | GNUtoo|laptop: answer in a few seconds, other tasks are building and ecore should come soon |
21:17.55 | GNUtoo|laptop | ok thanks |
21:18.01 | ericben | GNUtoo|laptop: ecare is configuring so the patch seems to be applied |
21:18.47 | GNUtoo|laptop | ah strange then |
21:18.51 | GNUtoo|laptop | I'll look |
21:18.54 | ericben | GNUtoo|laptop: 1 second I was not on head |
21:18.56 | GNUtoo|laptop | thanks a lot |
21:19.30 | GNUtoo|laptop | I suspect packaging staging and already-applied patches |
21:19.33 | ericben | GNUtoo|laptop: restarting build |
21:19.42 | GNUtoo|laptop | I cleaned and still nothing |
21:20.06 | GNUtoo|laptop | ahhh ok |
21:20.07 | GNUtoo|laptop | sorry |
21:20.13 | GNUtoo|laptop | basically I cleaned ecore |
21:20.16 | GNUtoo|laptop | and not ecore-native |
21:20.22 | GNUtoo|laptop | I only looked at the recipe name |
21:20.28 | GNUtoo|laptop | sorry |
21:21.20 | ericben | 3622 tasks remaining I was on stable ;) |
21:21.41 | ericben | so if you don't get news from me that means ecore_svn builds |
21:23.16 | GNUtoo|laptop | ericben, ^^^ |
21:23.22 | GNUtoo|laptop | should be an error from my side |
21:27.26 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * rf7f9648d31 10openembedded.git/recipes/vsftpd/vsftpd_2.0.5.bb: |
21:27.26 | CIA-101 | vsftpd-2.0.5: don't run pkg_postinst on host |
21:27.26 | CIA-101 | Signed-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.42 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r186d009f4c 10openembedded.git/recipes/libsdl/pushover_0.0.1.bb: |
21:33.43 | CIA-101 | libsdl: depend on virtual/libsdl instead of libsdl-x11 |
21:33.43 | CIA-101 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
21:33.45 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r1b5ee5b117 10openembedded.git/recipes/python/python-pygame_1.9.1.bb: |
21:33.45 | CIA-101 | python: depend on virtual/libsdl instead of libsdl-x11 |
21:33.45 | CIA-101 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
21:33.48 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r618653b0b6 10openembedded.git/recipes/efl1/ecore.inc: |
21:33.48 | CIA-101 | efl1: depend on virtual/libsdl instead of libsdl-x11 |
21:33.48 | CIA-101 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
21:33.50 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r561f8a77b5 10openembedded.git/recipes/vlc/ (vlc.inc vlc_0.9.2.bb): |
21:33.51 | CIA-101 | vlc: depend on virtual/libsdl instead of libsdl-x11 |
21:33.51 | CIA-101 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
21:34.04 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r062dbf9ad8 10openembedded.git/recipes/quake/ (4 files): |
21:34.04 | CIA-101 | quake: depend on virtual/libsdl instead of libsdl-x11 |
21:34.04 | CIA-101 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
21:34.16 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r18d59f5fad 10openembedded.git/recipes/ffmpeg/ (ffmpeg.inc ffmpeg_svn.bb): |
21:34.16 | CIA-101 | ffmpeg: set default license to GPLv2+, because --enable-gpl is used. |
21:34.16 | CIA-101 | * See http://www.ffmpeg.org/legal.html |
21:34.16 | CIA-101 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
21:34.21 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * re9e434d00a 10openembedded.git/recipes/libtheora/libtheora_0.9+1.0alpha7.bb: |
21:34.21 | CIA-101 | libtheora: depend on virtual/libsdl instead of libsdl-x11 |
21:34.21 | CIA-101 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
21:34.34 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * rba6079a882 10openembedded.git/recipes/nogravity/nogravity_2.0.bb: |
21:34.34 | CIA-101 | nogravity: depend on virtual/libsdl instead of libsdl-x11 |
21:34.34 | CIA-101 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
21:34.46 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * r6fccd90300 10openembedded.git/recipes/gstreamer/gst-plugins-bad_0.10.20.bb: |
21:34.46 | CIA-101 | gst-plugins-bad: update EXTRA_OECONF (mjpegtools, sdl) |
21:34.46 | CIA-101 | * Fix build with mjepegtools installed, by disabling mpeg2enc and mplex. |
21:34.46 | CIA-101 | The configure script of gst-plugins-bad wants to use AC_TRY_RUN for |
21:34.46 | CIA-101 | both of them, which doesn't work when cross-compiling. |
21:36.21 | obi | can 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.21 | Tartarus | We need to set a flag day or something for dropping bitbake 1.8 support |
21:39.29 | Tartarus | (and thus bumping python min up too) |
21:49.52 | Crofton|work | Tartarus, bug the tsc :) |
21:52.39 | *** join/#oe mrc3__ (~mrc3@nat/ti/x-jjjenzbzipnodbec) |
21:53.06 | tharvey | some 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.23 | mrj10 | tharvey: seems like it's conceivable that the canonical way to fetch a source may involve redirects |
21:55.53 | mrj10 | it 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.54 | tharvey | yes, I suppose so |
21:57.04 | mrj10 | URL 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.42 | mrj10 | maybe 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.57 | tharvey | ya... guess the best approach is to avoid using evil redirectors like opendns |
21:57.59 | mrj10 | check to see if the "file" utility recognizes it as it's purported file type |
21:58.13 | mrj10 | or if it's bigger than some nominal size, ~2KB |
21:58.33 | Tartarus | You know? |
21:58.41 | Tartarus | Optional integrity checking would be great |
21:58.56 | Tartarus | and catch these |
21:58.59 | tharvey | wouldn't want to avoid integrity check - in this case the fetch is foobar |
21:59.17 | Tartarus | Right |
21:59.23 | Tartarus | And the integrity check will catch |
21:59.27 | tharvey | more interested in detecting the bad fetch to go on and try a mirror instead of thinking its good |
21:59.33 | tharvey | oh... I follow |
21:59.54 | tharvey | you mean bitbake check the md5 and if fail try a mirror before bailing? |
21:59.58 | Tartarus | No |
21:59.59 | mrj10 | wait. tharvey, how does it continue if the md5sum is foobared? |
22:00.03 | Tartarus | I mean *.bz2 -> bzip2 -t |
22:00.05 | Tartarus | and so on |
22:00.12 | foerster | kergoth_: https://github.com/foerster/bitbake/commit/c5ec30133257d7cc1eda6fcec70dd4110e0769f4 |
22:00.24 | tharvey | mrj10, it doesn't continue - bitbake fails. What I'm after is avoiding the failure by trying a mirror |
22:00.32 | mrj10 | ah, i see |
22:00.39 | tharvey | Tartarus, that would work... |
22:00.47 | tharvey | like that better than assuming a filesize |
22:00.49 | mrj10 | strange that it doesnt do that already, seems like a good idea |
22:02.48 | tharvey | any 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.14 | ericben | khem: any idea concernign this gcc error : http://tinderbox.openembedded.net/public/logs/task/8666826.txt |
22:18.18 | ericben | ? |
22:20.18 | mrj10 | tharvey: 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.32 | ericben | khem: where trying samba-3.5.6 I get this one : http://pastebin.com/yuiYX2CM |
22:21.08 | tharvey | mrj10, that sounds like too much overhead to metadata - I like the optional quicktest of tarballs idea |
22:21.54 | grg | ericben, run the gcc command from the command line and try to reduce the compiler flags to identify if there is a culprit |
22:22.07 | foerster | kergoth_: depexp back to life now too: http://erafx.com/tmp/screenshot-depexp.png |
22:22.15 | kergoth_ | nice |
22:22.24 | ericben | grg: I'm trying to identify the reason |
22:22.42 | kergoth_ | 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.50 | kergoth_ | someday.. |
22:23.03 | foerster | yea. Well, now that we have some good basics back to functional, that's a start! |
22:23.10 | kergoth_ | yep, definitely |
22:23.12 | mrj10 | tharvey: 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.39 | kergoth_ | just realized he forgot to add i18n stuff to the TODO.. unicode chars in variable names, translation of bitbake internal messages, etc.. |
22:23.46 | mrj10 | i'm checking now whether libmagic (what "file <filename" on Linux et al. uses) supports the source file types we care about |
22:23.56 | foerster | kergoth_: goggle works, but it doesn't show much data other than tasks running |
22:24.15 | foerster | doesn't know what all it's supposed to do anyway |
22:24.36 | kergoth_ | either |
22:24.49 | kergoth_ | ugh |
22:24.49 | foerster | it used to capture MsgBase and take action based on MsgWarn, MsgError, etc |
22:25.02 | foerster | were those moved elsewhere into other event classes, or what? |
22:25.09 | kergoth_ | foerster: busybox do_configure hangs when using teh split server, not with master, somehow |
22:25.09 | mrj10 | kergoth: do we need more features or a more specialized tool than what already exists for navigating large graphviz graphs? |
22:25.24 | foerster | kergoth_: fml |
22:25.25 | foerster | :) |
22:25.26 | kergoth_ | foerster: we use LogRecord from the python logging module now, it carries a log level which translates to debug/warn/error/etc |
22:25.34 | foerster | is it T status? |
22:25.40 | kergoth_ | yep |
22:25.43 | mrj10 | e.g. http://code.google.com/p/jrfonseca/wiki/XDot , http://zvtm.sourceforge.net/zgrviewer.html http://www.kde.org/applications/graphics/kgraphviewer/ |
22:25.49 | foerster | how many levels deep? |
22:25.55 | foerster | php 5.3.3 does that to me |
22:25.57 | foerster | every time |
22:26.00 | kergoth_ | too many |
22:26.01 | kergoth_ | :) |
22:26.03 | foerster | but not in master |
22:26.14 | kergoth_ | the last 5 levels of processes are all T |
22:26.18 | foerster | i think it's doing it -- thinking we're a fork bomb maybe? |
22:26.22 | kergoth_ | hmm |
22:26.37 | kergoth_ | the weird thing is, the only difference between this and master is *ONE* extra process |
22:26.41 | kergoth_ | wtf? |
22:26.44 | foerster | i know |
22:27.04 | foerster | i have a new php recipe here for newest version which does the exact same. |
22:27.07 | foerster | no idea why |
22:27.17 | kergoth_ | 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.22 | kergoth_ | see if that helps |
22:28.26 | foerster | not sure, that's some bullshit though if the system thinks we're forkbombing :) |
22:28.52 | foerster | limit of num processes is umlimited here, so i dunno |
22:30.05 | kergoth_ | 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.11 | kergoth_ | but that wouldn' tmake any sense given master works |
22:30.36 | foerster | right, nothing in that regard changed |
22:31.35 | *** join/#oe julian_ (~julian@cpc3-cmbg14-2-0-cust129.5-4.cable.virginmedia.com) |
22:31.43 | kergoth_ | (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.01 | foerster | I haven't even looked in there yet |
22:32.23 | kergoth_ | does dup'ing of fds to get them redirected to the log or tee |
22:32.34 | kergoth_ | pre-subprocess that was probably a fine way to get it done, but.. |
22:33.07 | kergoth_ | this T thing is just strange. hmm |
22:33.10 | kergoth_ | googles |
22:33.21 | foerster | i couldn't find anything |
22:33.28 | kergoth_ | :( |
22:33.37 | foerster | the processes are being sent a SIGSTOP (or SIGTOSTOP, etc) |
22:33.42 | foerster | but i have no idea how to find out who |
22:34.03 | kergoth_ | my guess would be the kernel or the shell |
22:34.24 | foerster | hm |
22:35.11 | *** join/#oe ant__ (~andrea@host247-251-dynamic.14-87-r.retail.telecomitalia.it) |
22:35.35 | mrj10 | tharvey: 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.29 | foerster | let me know if you can find anything. This is the last biggie I think there is with the process server :) |
22:36.33 | foerster | i'm out for now |
22:36.34 | tharvey | sound more reasonable than looking for filename extensions |
22:36.34 | foerster | later |
22:36.48 | kergoth_ | later |
22:37.52 | mrj10 | yeah, it can detect a broader range of nefariousness on the part of your DNS provider, ISP, or other intermediaries (airport wifi gateway) |
22:40.32 | kergoth_ | heh, gotta love it when you wget a tarball and get an html file |
22:40.47 | tharvey | really annoying for sure |
22:42.08 | tharvey | kergoth_, what do you think about an optional per-type integrity check based off the magic of the file? |
22:42.24 | kergoth_ | doesn't seem unreasonable |
22:42.46 | kergoth_ | 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.36 | mrj10 | just checking the magic gets you 99.9% of the way there, it seems like |
22:45.48 | kergoth_ | nice |
22:47.32 | mrj10 | well, 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.19 | mrj10 | doesn'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.22 | kergoth_ | all of the fetching and unpacking stuff is likely to be rewritten in the near future |
22:48.39 | tharvey | what 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.41 | kergoth_ | 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.58 | mrj10 | oh, nice |
22:49.19 | kergoth_ | tharvey: i found a buildout that builds a local python of whatever version you like, and gives you a virtualenv for it |
22:49.26 | kergoth_ | that's what i usually use, personally |
22:49.48 | tharvey | sounds reasonable.... do you recall where you got it? |
22:50.12 | tharvey | heh... 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.24 | tharvey | in fact I would switch now if there was a quick simple howto for that |
22:51.01 | kergoth | if all you want is a chroot from a debian based system, its pretty straightforward |
22:51.04 | kergoth | debootstrap to build it |
22:51.15 | kergoth | then 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.05 | kergoth | tharvey: http://svn.plone.org/svn/collective/buildout/python |
22:52.33 | kergoth | then edit buildout.cfg and you can see what python versions it'll build, i just killed all but the one i wanted |
22:52.38 | kergoth | both under extends and parts |
22:52.45 | kergoth | then python bootstrap.py; bin/buildout |
22:52.48 | tharvey | so 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.16 | kergoth | what distro are you running? |
22:55.13 | tharvey | ubuntu |
22:55.19 | *** join/#oe Splat1 (~Splat1@rf1.splat1.com) |
22:56.19 | tharvey | ubuntu 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.47 | tharvey | liked 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.14 | CIA-101 | 03Philip 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.15 | CIA-101 | 03Philip 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.44 | kergoth_ | tharvey: debootstrap can build either debian or ubuntu chroots of a variety of versions |
23:02.55 | kergoth_ | hmm |
23:03.02 | kergoth_ | not sure how old they go though |
23:03.21 | kergoth_ | for rpm based distros there are a few similar tools, febootstrap, mock, etc |
23:03.32 | kergoth_ | was trying to construct a set of useful chroots at one point |
23:04.05 | tharvey | ah... I thought it just built from your host system - I'll read up on it - thanks |
23:04.09 | kergoth_ | 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.21 | kergoth_ | no, it pulls the packages from the apt feeds for what its building |
23:05.33 | tharvey | what is diff between debootstrap and cdebootstrap? |
23:05.40 | kergoth_ | no idea :) |
23:05.48 | kergoth_ | last time i tried the c one though it didn't have the config files necessary to do much |
23:05.52 | kergoth_ | i'd stick to the regular one |
23:05.55 | tharvey | k |
23:06.18 | kergoth_ | do a dpkg -L debootstrap|grep debootstrap/scripts |
23:06.23 | kergoth_ | those are the ones you have to choose from |
23:06.35 | kergoth_ | 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.24 | kergoth_ | ah ha |
23:25.50 | kergoth_ | 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.58 | kergoth_ | SIGTTIN looks promising here |
23:26.07 | kergoth_ | the question is why the behavior would be different with the server |
23:26.08 | kergoth_ | hmmmm |
23:30.38 | kergoth_ | oh fuck it, i'm changing bb.build to use subprocess |
23:31.02 | Crofton|work | arg |
23:31.19 | Crofton|work | i2c-dev.h gets staged from two packages it appears |
23:31.58 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |
23:34.26 | Jay7 | kergoth_: is bb master usable now? |
23:50.11 | kergoth_ | Jay7: should be, yes |
23:50.17 | kergoth_ | its all i use |
23:50.29 | Jay7 | ok, I'll run TB tonight |
23:50.50 | Jay7 | will build images for my zauruses to test on real HW |
23:50.55 | Jay7 | weekend is coming :) |
23:52.07 | kergoth_ | :) |
23:52.11 | Jay7 | seems perl is problem for yocto/poky too |
23:54.10 | Crofton|work | People who write Makefiles by hand should be shot |
23:54.40 | Crofton|work | i2c-tools installs a file called i2c-dev.h into include/linux |
23:54.47 | Crofton|work | over writing the version from the kernel |
23:54.54 | kergoth_ | there we go |
23:55.03 | kergoth_ | bb.build uses bb.process, which is oe.process, which uses subprocess |
23:55.04 | kergoth_ | :) |
23:55.16 | kergoth_ | *much* simpler |
23:55.52 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |