00:00.08 | Jay7 | khem: well, what about our build? |
00:00.24 | reactor16 | any one use dreambox ? |
00:01.03 | Jay7 | I have no idea about device_table and locale-base-fr-fr bugs.. |
00:03.27 | Jay7 | tried to clean glibc and rebuild |
00:03.30 | Jay7 | w/o success |
00:03.46 | Crofton | any idea how to use gmail for smtp, but not have your gmail address show up in the email? |
00:04.21 | Jay7 | ah.. seems it is using eglibc |
00:04.47 | Tartarus | Crofton, does gmail handle the domain or no? |
00:04.53 | Tartarus | if no, I think you can't |
00:05.07 | Crofton | ok |
00:05.26 | Jay7 | Crofton: use envelope-from? |
00:05.46 | Crofton | isn't working |
00:05.54 | Jay7 | heh.. seems gmail is too smart |
00:06.16 | Crofton | yeah |
00:06.17 | Jay7 | did you have your address attached to gmail into gmail account settings? |
00:06.43 | Jay7 | i.e. as address from which you can send mail via web-interface |
00:07.11 | ka6sox-work | morning |
00:08.14 | Crofton | Jay7, trying that now |
00:08.40 | *** part/#oe robtow (~a0272704@nat/ti/x-bzdssvkvtxurgnve) |
00:08.41 | Jay7 | as other option register separate account specially for this :) |
00:09.03 | Crofton | ah |
00:09.11 | Crofton | I think this worked, thanks JaMa|Off |
00:09.13 | Jay7 | btw, gmail can use 'plussed' addresses iirc |
00:09.14 | Crofton | Jay7, |
00:09.35 | Jay7 | yourmail+something@gmail.com |
00:10.22 | Jay7 | I've even heard that it can mark mail arriving to such address with 'something' label |
00:10.33 | Jay7 | but have not checked this |
00:10.55 | kergoth_ | its not automatic, you have to create filters for it |
00:11.00 | kergoth_ | but its doable easily enough |
00:11.28 | *** join/#oe robtow (~a0272704@nat/ti/x-kpfzkddbkuqpphju) |
00:12.58 | Crofton | adding the address I am subscribed to the OE list from to my gmail account worked |
00:13.21 | Jay7 | cool |
00:13.40 | Jay7 | Crofton: can you write some short instructions on wiki? |
00:13.54 | Jay7 | about using git-send-email |
00:14.39 | Crofton | I copied from the wiki |
00:14.46 | Crofton | I suppose I could add some notes |
00:14.53 | Jay7 | ah.. good :) |
00:16.20 | Jay7 | wow |
00:16.32 | Jay7 | khem: build was finished |
00:17.10 | Jay7 | I've rebuild eglibc w/o GLIBC_GENERATE_LOCALES |
00:17.39 | Jay7 | but requiring fr_FR locale is wrong imho |
00:17.50 | ant__ | Jay7: hey |
00:17.59 | Jay7 | classes/image.bbclass:IMAGE_LINGUAS ?= "de-de fr-fr en-gb" |
00:18.00 | Jay7 | haha |
00:18.07 | kergoth_ | that's a really lame default |
00:18.13 | kergoth_ | also, arbitrary |
00:18.19 | Jay7 | forgotten imho |
00:18.34 | kergoth_ | 's had that overridden in his site.conf for so long he probably forgot about it |
00:18.39 | ant__ | I'm deleting some old tmpdirs..the eglibc was fine *withy* locales generation |
00:18.56 | kergoth_ | damnit, i broke the bitbake cache somehow.. hrm |
00:19.14 | ant__ | s@i+...can't get used to this new kb |
00:19.20 | Jay7 | well.. so, I should note that GLIBC_GENERATE_LOCALES should be consistent with IMAGE_LINGUAS then |
00:20.09 | Jay7 | btw, lot of images have it overriden |
00:20.33 | Jay7 | well, ok |
00:20.52 | Jay7 | khem: build successed anyway |
00:21.01 | Jay7 | so you can push that changes |
00:22.37 | ant__ | kergoth_: I noticed some/most images are setting IMAGE_BASENAME.. |
00:22.44 | kergoth_ | they should be, yes |
00:22.51 | ant__ | well, exporting |
00:22.53 | *** join/#oe kerim (~kerim@188.3.59.15) |
00:23.05 | kergoth_ | oh, that's silly |
00:23.36 | ant__ | is it even whitelisted? |
00:23.47 | kergoth_ | not sure what you mean |
00:23.49 | ant__ | ah ha..first grep match.. |
00:23.59 | ant__ | ./classes/image.bbclass:# "export IMAGE_BASENAME" not supported at this time |
00:24.13 | kergoth_ | that just means its doing IMAGE_BASENAME[export] = "1" |
00:24.20 | kergoth_ | due to old bitbake not supporting the export directive without = |
00:24.27 | ant__ | k |
00:24.32 | kergoth_ | doesn't explain why its being exported at all :) |
00:24.40 | ant__ | still it seems to me unnecessary |
00:24.43 | kergoth_ | yep |
00:24.44 | kergoth_ | i agree |
00:24.44 | ant__ | right |
00:32.50 | Jay7 | seems I should setup git-send-email too.. |
00:41.27 | kergoth_ | grumbles |
00:44.49 | ant__ | late here...good night |
00:51.26 | *** join/#oe kgilmer (~kgilmer@i114-182-187-151.s06.a014.ap.plala.or.jp) |
00:55.53 | Jay7 | khem: I've posted patch to ML |
00:55.53 | ka6sox-work | khem, ping? |
00:58.14 | *** part/#oe mrj10 (~mrj10@mjlap.crhc.uiuc.edu) |
01:02.29 | Crofton | Any ideas? |
01:02.30 | Crofton | http://tinderbox.openembedded.org/public/logs/task/10211209.txt |
01:02.37 | Crofton | tracker dies looking for hal |
01:08.14 | Jay7 | Crofton: what is in config.log? |
01:08.31 | Crofton | not sure |
01:08.43 | Crofton | I am trying to bitbake hal and restarting is my guess |
01:12.02 | Jay7 | have started testbuilder for minimal distro and goes sleep |
01:12.48 | Crofton | gn |
01:13.35 | ka6sox-work | Jay7, are you still using that spreadsheet? |
01:14.03 | Jay7 | Crofton: btw, have you seen your mail in your gmail.com mailbox? |
01:14.19 | Crofton | which email? |
01:14.32 | Jay7 | which was sent by git-send-email |
01:14.34 | Crofton | the confirmation email for the new address goes to that ddress |
01:14.53 | Jay7 | ka6sox-work: I've not updated it |
01:14.54 | Crofton | I thnk it stopped going there |
01:15.17 | Jay7 | ka6sox-work: have nothing new to show.. |
01:15.51 | Crofton | ok tracker is compiling now |
01:15.51 | Jay7 | I've sent my patch to ML by git-send-email but I don't see it in inbox |
01:16.00 | Crofton | looks like it need some form of depends on hal |
01:16.10 | Crofton | uses a multi core builder |
01:17.19 | ka6sox-work | Jay7, thanks. |
01:17.28 | ka6sox-work | multi-core only means it fails faster. |
01:18.17 | Jay7 | :)) |
01:18.36 | Jay7 | ka6sox-work: btw, I'm using 4/2 threads now |
01:18.56 | Tartarus | Jay7: BB/make or make/BB ? |
01:19.00 | Jay7 | bb/make |
01:19.16 | Tartarus | tried tuning it up higher? |
01:19.25 | Jay7 | seems more bb threads will not produce better time.. |
01:19.26 | Tartarus | is starting to question his rule of thumb there |
01:19.31 | ka6sox-work | Jay7, kewl! that should help to keep it out of iowait. |
01:19.38 | Jay7 | HDD bw limit reached |
01:19.59 | Jay7 | but I should analyze vmstat output.. |
01:20.16 | ka6sox-work | right..thats why multi-core and the rule of J#= 2X number of Cores FAILS. |
01:20.41 | Tartarus | I had been doing -j#*1.5, threads=N |
01:20.56 | ka6sox-work | above 2cores and -j 4 seems to hit a wall. |
01:21.11 | Jay7 | ideal case is bb threads == No of cores and -j2 :) |
01:21.33 | Tartarus | it's sure true that very few things can make use of larger -j numbers |
01:21.41 | Tartarus | gcc and *glibc and that's about it |
01:22.05 | Jay7 | I've tought today about distributed building system |
01:22.59 | ka6sox-work | Jay7, I'm thinking about 2 cores on each of 4 machines with -j4 and icecc |
01:23.01 | Jay7 | nothing useful.. |
01:23.28 | ka6sox-work | but autoconfig and other things will slow that down. |
01:23.34 | Tartarus | yeah |
01:23.43 | Jay7 | ka6sox-work: 4 cores have almost the same price imho |
01:23.49 | Tartarus | That's one of the bottlenecks to making icecc a win over single big boxe |
01:23.50 | Tartarus | s |
01:23.51 | Jay7 | +- 20$ :) |
01:24.12 | *** join/#oe fraxinath (~quassel@p4FD651F3.dip.t-dialin.net) |
01:24.14 | ka6sox-work | Jay7, its mostly about I/O BW...not cores |
01:24.21 | Jay7 | Phenom II X4 is very cheap now |
01:24.37 | Tartarus | 'now'? heh, I don't wanna know how cheap they are now |
01:24.40 | Jay7 | see, I'm using 4/2 :) |
01:24.46 | Tartarus | got one when they were kinda new and would have sworn it was cheap then |
01:24.51 | ka6sox-work | really...its *all* about I/O BW when building |
01:25.01 | Tartarus | model name : AMD Phenom(tm) II X4 940 Processor |
01:25.05 | Tartarus | is what i've got local |
01:25.27 | Jay7 | Tartarus: I've awaited for X6 and got it now :) |
01:25.29 | ka6sox-work | I have 2ea 2378's |
01:25.37 | ka6sox-work | so 8 cores. |
01:25.54 | Jay7 | there are 12-cored opterons already.. |
01:26.54 | Jay7 | I should sleep! |
01:27.07 | ka6sox-work | nn Jay7 |
01:27.09 | ka6sox-work | sleep well. |
01:36.26 | Tartarus | khem: Still fails, still -O2 not -Os |
01:45.57 | *** join/#oe balister_ (~balister@adsl-75-37-22-143.dsl.pltn13.sbcglobal.net) |
02:05.02 | *** join/#oe mnabil (~mnabil@41.234.70.134) |
02:06.53 | *** join/#oe mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net) |
02:10.56 | *** join/#oe Crofton (~balister@adsl-75-37-22-143.dsl.pltn13.sbcglobal.net) |
02:18.08 | *** join/#oe rednul (~rednul@host-174-45-250-246.bln-mt.client.bresnan.net) |
02:20.18 | *** join/#oe kergoth (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
02:38.50 | *** join/#oe kgilmer (~kgilmer@i114-180-120-196.s06.a014.ap.plala.or.jp) |
02:39.56 | *** join/#oe playya__ (~playya@93.216.253.97) |
02:39.56 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
03:04.57 | *** join/#oe fraxinas (~quassel@p4FD6574D.dip.t-dialin.net) |
03:10.07 | kergoth | meh |
03:14.08 | *** join/#oe mfhk (~chatzilla@cm61-15-76-62.hkcable.com.hk) |
03:16.16 | kergoth | hrm, for some reason the recipeinfo changes result in not reparsing some recipes when a cache is in place that were reparsed without the changes.. |
03:16.20 | kergoth | tries to track down why |
03:17.11 | khem | kergoth: I am bewildered |
03:17.18 | khem | there is this git repo |
03:17.27 | khem | if I clone it manually works all ok |
03:17.34 | khem | but bitbake fetcher is failing |
03:17.41 | kergoth | what's the failure? |
03:18.25 | khem | "git://gitorious.org/efikamx/linux-kernel.git;protocol=git" |
03:19.49 | khem | http://pastebin.com/4gNUc1Xi |
03:20.12 | kergoth | weird |
03:20.19 | kergoth | that same command works at a commandline? |
03:21.50 | khem | <PROTECTED> |
03:21.53 | khem | works |
03:22.37 | kergoth | weird. |
03:22.39 | kergoth | hmm |
03:22.56 | khem | I have two gits |
03:22.59 | khem | and both work |
03:23.10 | khem | one is from native staging |
03:23.30 | kergoth | no idea, that's a strange one |
03:23.43 | khem | it happens all the time |
03:27.21 | mfhk | I am going to buy an Android phone, which model would work with OE in the near future? |
03:33.57 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
03:37.44 | khem | mfhk: well HTC seems to working with oe |
03:48.36 | kergoth | hacks on bb.cache some more |
04:02.13 | kergoth | damnit, with this patch applied: 6816 cached, 387 parsed. without: 6791 cached, 412 parsed. |
04:02.17 | kergoth | mutters |
04:07.10 | kergoth | does https://github.com/kergoth/bitbake/compare/master...parallel-parsing-prep seem sane, looking over the diff? |
04:08.34 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
04:20.09 | *** join/#oe kgilmer (~kgilmer@i60-35-211-38.s06.a014.ap.plala.or.jp) |
04:38.58 | *** join/#oe playya__ (~playya@93.216.253.97) |
04:38.58 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
05:12.39 | *** join/#oe mrj10 (~mrj10@63.252.64.254) |
05:51.05 | *** join/#oe dth (~dth@a89-183-11-169.net-htp.de) |
06:10.04 | *** join/#oe xobs (~smc@cm152.psi156.maxonline.com.sg) |
06:12.06 | *** join/#oe BlindMan (~othmar@h081217021188.dyn.cm.kabsi.at) |
06:19.10 | *** join/#oe rednul (~rednul@209-193-110-226.mammothnetworks.com) |
06:29.31 | *** join/#oe rednul (~rednul@209-193-110-226.mammothnetworks.com) |
06:34.48 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
06:48.36 | *** join/#oe aloril (~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) |
06:52.23 | *** join/#oe Jay7 (jay@93-81-136-11.broadband.corbina.ru) |
06:56.17 | eFfeM_work | gm |
06:58.28 | eFfeM_work | khem you still here ? |
07:07.41 | *** join/#oe guufy (~Guufy@c-24-130-108-191.hsd1.ca.comcast.net) |
07:09.38 | *** join/#oe russ (foobar@ip70-176-251-1.ph.ph.cox.net) |
07:17.55 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
07:32.24 | *** join/#oe anarsoul_ (~anarsoul@80.249.95.238) |
07:34.07 | *** join/#oe rob_w (~bob@77.74.119.145) |
07:38.31 | mckoan | good morning |
07:56.16 | *** join/#oe rschus (~rschus@251.118.101-84.rev.gaoland.net) |
07:59.13 | *** part/#oe russ (foobar@ip70-176-251-1.ph.ph.cox.net) |
08:12.22 | *** join/#oe likewise (~chatzilla@82-170-243-215.ip.telfort.nl) |
08:13.23 | likewise | gm |
08:19.50 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
08:28.49 | *** join/#oe vps (~vitus@145.253.169.210) |
08:36.16 | *** join/#oe nani__ (7aa60de8@gateway/web/freenode/ip.122.166.13.232) |
08:36.35 | *** join/#oe thaytan (~jan@ppp59-167-167-201.static.internode.on.net) |
08:53.43 | *** join/#oe rschus1 (~rschus@251.118.101-84.rev.gaoland.net) |
08:54.07 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
08:55.14 | *** join/#oe dth_ntb (~dth@a89-183-78-30.net-htp.de) |
08:55.39 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
09:07.15 | *** join/#oe laurent__ (~laurent@dslb-084-057-049-016.pools.arcor-ip.net) |
09:15.09 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
09:20.02 | *** join/#oe arun_ (~arun@j163077.upc-j.chello.nl) |
09:20.02 | *** join/#oe arun_ (~arun@unaffiliated/sindian) |
09:21.38 | *** join/#oe atiti (~atiti@port492.ds1-bav.adsl.cybercity.dk) |
09:23.58 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
09:28.24 | CIA-71 | 03Chase Maupin <Chase.Maupin@ti.com> 07org.openembedded.dev * r64db5346f3 10openembedded.git/recipes/u-boot/u-boot_git.bb: |
09:28.25 | CIA-71 | u-boot_git: use SOC_FAMILY for omapl devices |
09:28.25 | CIA-71 | * Use the SOC_FAMILY override for omapl137 and omapl138 based |
09:28.25 | CIA-71 | devices. |
09:28.25 | CIA-71 | Signed-off-by: Chase Maupin <Chase.Maupin@ti.com> |
09:28.25 | CIA-71 | Signed-off-by: Koen Kooi <k-kooi@ti.com> |
09:28.26 | CIA-71 | 03Koen Kooi <k-kooi@ti.com> 07org.openembedded.dev * rabcc9c2948 10openembedded.git/recipes/linux/linux-davinci_git.bb: |
09:28.27 | CIA-71 | linux-davinci git: update hawkboard |
09:28.27 | CIA-71 | Signed-off-by: Koen Kooi <k-kooi@ti.com> |
09:28.27 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
09:28.28 | CIA-71 | 03Chase Maupin <Chase.Maupin@ti.com> 07org.openembedded.dev * rb64297415c 10openembedded.git/conf/machine/am180x-evm.conf: |
09:28.28 | CIA-71 | am180x-evm: Add am180x-evm machine type |
09:28.28 | CIA-71 | * Add new machine type for the AM180x family of devices. These |
09:28.29 | CIA-71 | devices are part of the omapl138 SOC_FAMILY. |
09:28.29 | CIA-71 | Signed-off-by: Chase Maupin <Chase.Maupin@ti.com> |
09:30.11 | Jay7 | hm.. it thought that bb of image for efikamx is hang but seems it was fetching kernel image from git.. |
09:30.35 | Jay7 | well, x11-image should redo the task |
09:30.59 | *** join/#oe blindvt_ (~bf@84.119.101.28) |
09:33.04 | *** join/#oe Splat1 (~Splat1@rf1.splat1.com) |
09:42.24 | *** part/#oe JaMa|Off (~martin@161-24.13.24.78.awnet.cz) |
09:44.46 | *** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net) |
09:47.33 | *** join/#oe obi (~obi@unaffiliated/obi) |
10:01.57 | *** join/#oe vps (~vitus@145.253.169.210) |
10:02.28 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
10:05.25 | *** join/#oe kgilmer (~kgilmer@pl258.nas932.kofu.nttpc.ne.jp) |
10:09.57 | *** join/#oe PS (~root@115.119.134.194) |
10:10.01 | eFfeM_work | hm, anyone ever got this while building: |
10:10.06 | eFfeM_work | sh: /home/frans/workspace/SYHL1_1/C/Linux/openembedded/tmp/staging/x86_64-linux/bin/quilt: /bin/bash: bad interpreter: Text file busy |
10:10.24 | eFfeM_work | this is ubuntu 10.04, /bin/bash exists |
10:10.43 | eFfeM_work | is puzzled but thinks kicking the build again might allow it to proceed |
10:10.56 | ka6sox-work | eFfeM_work, yes, and I don't remember what fixed it...too late here. |
10:11.19 | eFfeM_work | i'll see if it is repeatable |
10:11.43 | eFfeM_work | apparently not; a new build does not give the error |
10:12.37 | eFfeM_work | khem, uclibc++ patch posted, would especially like to see your feedback on the cstring patch (which might not be good, but at least it got things compiling :-) ) |
10:14.49 | *** join/#oe Heinervdm (~thomas@pD9E16BD5.dip.t-dialin.net) |
10:15.04 | *** join/#oe zub (U2FsdGVkX1@linux.fjfi.cvut.cz) |
10:17.15 | ericben | good morning |
10:17.25 | ant_work | eFfeM_work: there are still some race issues, it seems |
10:17.57 | eFfeM_work | guess so, but text file busy is probably an OS or bash issue |
10:18.01 | eFfeM_work | hi ericben |
10:18.07 | ant_work | at least I solved a repeatable one: lzma-native |
10:18.19 | eFfeM_work | ah, cool |
10:18.26 | ant_work | imagine removing an unneeded dependency cured the thing... |
10:18.30 | ant_work | strange |
10:18.33 | eFfeM_work | also would like to understand the preferred provider thing, see my reply on your mail |
10:18.39 | ant_work | yep |
10:18.56 | ant_work | and documentation about PREFERRED_VERSION_pn |
10:19.08 | ericben | when adding PACKAGE_ARCH = ${MACHINE}, should'nt the workdir be tmp/work/${MACHINE}-angstrom-linux-gnueabi ? |
10:20.21 | eFfeM_work | ericben: probably (depends on the triplet, and ofc only if you are building for angstrom) |
10:20.42 | ant_work | eFfeM_work: see Re: [oe] [PATCH (v2)] Reverse the order of OVERRIDES |
10:20.44 | eFfeM_work | I also have this: ppce500v2-oe-linux-gnuspe |
10:20.48 | ant_work | outstanding issue imho |
10:21.20 | eFfeM_work | ant_work: that's why I added the _local |
10:22.08 | eFfeM_work | actually I seem to recall a reply from RP that this introduces an incompatibility between oe and yocto/poky so not too sure that patch is a good plan |
10:22.16 | eFfeM_work | would love to see the _target override though |
10:22.29 | ericben | I have a strange behaviour here (on qt4 embedded recipe, amended in an overlay for a machine) : the workdir is armv6-angstrom... , but the package is machine specific in the end which is correct. The problem is when building meta-toolchain-qte, I get this error : cp: cannot stat `/scratch/tests/101116/cpuimx35/tmp_angstrom-2010.x_eukrea-cpuimx35/pkgdata/eukrea-cpuimx35-angstrom-linux-gnueabi/qt4-embedded': No such file or directory |
10:23.03 | ericben | so meta-toolchain-qte search for qt4-embedded in the machine dirs when it's built in the arch dir |
10:23.31 | ericben | do you have an idea of where I should search for this problem ? |
10:26.32 | eFfeM_work | strange |
10:26.47 | ericben | yes I agree with you :-D |
10:26.52 | eFfeM_work | not really an idea, not something I have too much knowledge about |
10:27.13 | ericben | this was working fine before, so I'm searching for the comit which broke this |
10:32.12 | eFfeM_work | is the problem repeatable ? (have you tried to rm tmp and does it resurface) ? |
10:32.35 | eFfeM_work | i expect this to be something in the class stuff |
10:32.54 | ericben | in fact I found this when doing a clean build from scratch |
10:33.39 | ericben | I have overlay + amend.inc + FILESPATHBASE change to pick files from overlays |
10:34.40 | ericben | I'm goiing to try some testing tags to find when that broke |
10:44.07 | eFfeM_work | seems ok with me, but I'm not too good with amend.inc somehow it didn't work for me the way I wanted it (and neither did .bbclass) but didn't dive into it yet, guess that was something at my side) |
10:52.12 | blindvt` | kergoth_, is there a subtile reason why there are soooo many 'p' in Fetch::suppports_srcrev() ? If not i'll rename it in master, fwiw |
10:53.28 | blindvt` | (osc has this wrong -- since it's using just 2 'p' ;) |
11:01.28 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
11:02.44 | ericben | eFfeM_work: that seems to be a problem in amend.inc. setting PACKAGE_ARCH = "${MACHINE}" in oe's recipe works fine |
11:05.25 | blindvt` | kergoth_, can we use bz2 or no compression at all (instead of .gz) for packing checkouts or do you think that doesn't make sense or won't be used? Just an idea.. |
11:07.42 | ynezz | does it happen only to me? http://pastebin.com/6RE7417z |
11:08.55 | ericben | ynezz: this happens also to me ... when I have a mistake somewhere in a recipe |
11:09.14 | ericben | the hardest thing is to find where is the mistake as bitbake doesn't provide any log for this |
11:09.14 | ynezz | but it's testing-next from 12th November and bitbake master |
11:09.17 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
11:09.36 | ynezz | that's why I'm asking :) |
11:09.38 | ericben | ynezz: ah interesting :) |
11:13.37 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |
11:20.51 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
11:21.04 | *** join/#oe Radioo (~Radio@port-87-193-237-134.static.qsc.de) |
11:24.39 | Radioo | Hello, someone has an idea how to fix this build error with OE: http://pastebin.com/xhZmvqQs ? |
11:33.59 | *** join/#oe bandwidthcrunch (~quassel@122.166.104.245) |
11:35.12 | bandwidthcrunch | I have a 1024x600 resolution on my lcd . Any pointers where can i specify for OE to be built for that screensize |
11:45.52 | *** join/#oe etrunko (~edulima@187.106.5.201) |
11:48.41 | ynezz | hm, the parsing error is in openssl recipe and fails also with bitbake 1.10.1 |
11:48.52 | ynezz | but I can't clearly see why |
11:49.27 | ynezz | http://pastebin.com/55kJwULL |
11:49.57 | ynezz | ParsingErrorsFound is really sparse error message :) |
11:54.50 | *** join/#oe B_Lizzard (~havoc@athedsl-433524.home.otenet.gr) |
11:59.35 | *** join/#oe bandwidthcrunch (~quassel@122.166.104.245) |
12:00.37 | *** join/#oe JaMa (~martin@161-24.13.24.78.awnet.cz) |
12:01.52 | *** join/#oe Proxyles (~henrik@c83-253-27-91.bredband.comhem.se) |
12:07.21 | *** join/#oe otavio (~otavio@debian/developer/otavio) |
12:07.52 | ericben | eFfeM_work: I found the problem ! changing PACKAGe_ARCH in amend.inc doesn't work because MULTIMACH_ARCH is already set and is the variable used for the workdir path for example |
12:07.57 | ericben | e |
12:08.48 | ericben | eFfeM_work: setting PACKAGE_ARCH *and* MULTIMACH_ARCH to ${MACHINE} in amend.inc seems to do the trick |
12:10.33 | CIA-71 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r9be2cf18ce 10openembedded.git/recipes/ (5 files in 3 dirs): (log message trimmed) |
12:10.33 | CIA-71 | jlime,dzen2,puzzles: use RDEPENDS_${PN} |
12:10.33 | CIA-71 | * it was fixed in whole tree about half year ago |
12:10.33 | CIA-71 | http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-June/020384.html |
12:10.33 | CIA-71 | http://comments.gmane.org/gmane.comp.handhelds.openembedded/33440 |
12:10.33 | CIA-71 | * then again about month ago |
12:10.34 | CIA-71 | http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg11356.html |
12:10.53 | JaMa | someone building micro+eglibc? |
12:11.20 | JaMa | for some reason stdio.h isn't in sysroot after building from scratch for me (and eglibc-initial fails to configure) |
12:17.05 | *** join/#oe laurent__ (~laurent@dslb-084-057-015-185.pools.arcor-ip.net) |
12:20.39 | *** join/#oe Openfree (~df@61.170.206.160) |
12:24.20 | *** join/#oe screwgoth (~raseel@122.170.63.153) |
12:34.51 | eFfeM_work | ericben: ah ok, good find, guess we should document it somewhere |
12:35.55 | eFfeM_work | ynezz: try running bitbake -v -v -v -D -D -D recipename |
12:37.15 | *** join/#oe yonathanaw (~quassel@122.166.104.245) |
12:39.32 | ericben | eFfeM_work: yes I'll send a mail to the list explaining the thing |
12:47.38 | *** join/#oe GarthPS (~quassel@92.90.21.1) |
12:49.26 | *** join/#oe martinambrose (~martinamb@c-98-198-169-228.hsd1.tx.comcast.net) |
12:50.12 | *** join/#oe martinambrose (~martinamb@c-98-198-169-228.hsd1.tx.comcast.net) |
12:55.28 | *** join/#oe GarthPS|away (~quassel@92.90.21.1) |
12:56.18 | eFfeM_work | JaMa: suggest writing an email to list with cc to alex and kristoffer on the RDEPENDS thingie |
12:56.33 | *** join/#oe B_Lizzard (~havoc@athedsl-433524.home.otenet.gr) |
12:59.01 | *** join/#oe GarthPS (~quassel@92.90.17.1) |
13:00.38 | *** join/#oe GarthPS|away (~quassel@92.90.21.1) |
13:01.04 | *** join/#oe marex (~marex@eduroam4.ms.mff.cuni.cz) |
13:02.41 | *** join/#oe Openfree^ (~Openfree`@61.170.206.160) |
13:02.56 | *** join/#oe GarthPS|away (~quassel@92.90.17.5) |
13:09.23 | JaMa | eFfeM_work: well I replied to oe-devel an oe-commits when I noticed in their recipes without any reaction... so I just pushed it |
13:12.23 | eFfeM_work | yeah, now recall the reply (was probably between the 600 messages or so that where in my box after being away for a week) |
13:13.49 | JaMa | eFfeM_work: btw did you notice that your libx11 change is already applied upstream? |
13:14.00 | JaMa | so next libx11-1.4 snapshot will have it |
13:14.10 | eFfeM_work | cool, will get to it later |
13:14.14 | eFfeM_work | now busy |
13:14.28 | JaMa | ok :) |
13:22.14 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
13:24.21 | *** join/#oe GNUtoo|laptop (~gnutoo@95.232.144.102) |
13:25.26 | obi | what's the correct way of moving a file from one package to another without breaking upgrades? |
13:25.43 | *** join/#oe marex (~marex@eduroam4.ms.mff.cuni.cz) |
13:26.01 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
13:26.44 | JaMa | obi: RREPLACES_old = new |
13:28.08 | obi | i think this will only work if the old package should be removed |
13:28.25 | obi | but i already have both packages installed and want to keep both packages after the upgrade |
13:28.48 | JaMa | that's RCONFLICTS_ |
13:29.13 | pb_ | JaMa: the other way around, surely. "RREPLACES_new = old". |
13:29.13 | JaMa | but better to test first I'm not 100% sure |
13:29.24 | pb_ | seems a bit unreasonable to expect the old packages to predict which new ones will be invented to replace them :-} |
13:29.30 | JaMa | pb_: ah right |
13:31.52 | obi | JaMa: you mean something like RCONFLICTS_new = "old (<$version)"? can version include the PR? the only similar occurence in git looks like this: RCONFLICTS_${PN}-tshark = "tshark wireshark (<1.0.5)" |
13:34.16 | JaMa | obi: but that's if you need to remove whole old package before installing new one |
13:34.52 | JaMa | RREPLACES can be used if new package only partially replaces old one (that's our case isn't it?) |
13:35.26 | JaMa | and I'm not sure that RCONFLICTS are automatically resolved during opkg upgrade |
13:35.37 | JaMa | user maybe have to remove it manually first |
13:35.51 | obi | ah, yes, i see. my guess was that RREPLACES indicates a replacement for an obsolete package |
13:38.18 | obi | but my question regarding the PR remains the same, since RREPLACES_${PN} = "tshark wireshark (<1.0.5)" is again the only package with specifies a version |
13:39.33 | pb_ | obi: do you actually need to specify a version? |
13:39.37 | JaMa | I don't think you have to wrote version there |
13:41.08 | obi | i think so, because i want to upgrade the old package instead of removing it |
13:41.12 | obi | the documentation says: |
13:41.18 | obi | RREPLACES |
13:41.18 | obi | <PROTECTED> |
13:41.38 | pb_ | I think that documentation is wrong. |
13:42.36 | obi | ok |
13:42.44 | *** join/#oe GNUtoo (~GNUtoo@95.232.144.102) |
13:42.55 | *** join/#oe mnabil (~mnabil@41.234.70.134) |
13:43.49 | obi | i think i should specify a version, because the new package should not replace the upgraded old package ;) |
13:44.20 | obi | but in the specific case i'm probably able to bump the version of the old package, making the PR irrelevant |
13:44.35 | eFfeM_work | JaMa: wrt the x11 patch,did they apply it just as we gave it? seem to recall there was a change proposal |
13:45.05 | eFfeM_work | but in any case: can we create a similar patch for the current version and apply that one ? |
13:45.07 | JaMa | eFfeM_work: no changed |
13:45.15 | eFfeM_work | ah so we can just push |
13:45.20 | JaMa | and then changed host<->target var |
13:45.44 | JaMa | eFfeM_work: I meant: no, changed :) |
13:45.51 | eFfeM_work | ah ok |
13:45.57 | eFfeM_work | yeah that was discussed |
13:46.10 | JaMa | http://cgit.freedesktop.org/xorg/lib/libX11/log/ |
13:46.51 | foerster | fml. PHP forcefully disables libdl when cross compiling, meaning I can't (easily) get any extensions to work. hmm. Any autoconf gurus around with some hints? |
13:46.52 | eFfeM_work | can you add that patch to the current libx121 ? |
13:46.59 | eFfeM_work | JaMa: ^ |
13:47.10 | eFfeM_work | been involved in other problems over my ears atm |
13:47.58 | JaMa | too and leaving in few minutes, sorry |
13:48.04 | JaMa | also no nios to test it :) |
13:48.06 | eFfeM_work | ah ok, np |
13:51.06 | Tartarus | forester, does it just not test for it being supported? |
13:51.10 | Tartarus | That's just another site variable |
13:51.11 | *** join/#oe mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net) |
13:52.36 | foerster | Tartarus: it checks if it can find dlopen directly, then tries by linking with -ldl . Since cross compiling, the default is set to no automatically. |
13:53.00 | foerster | I tried setting a site variable, but they do unset ac_cv_* before running tests. |
13:53.54 | Tartarus | OK, wow, that sounds pretty broken |
13:54.07 | Tartarus | I'd go and patch the configure scripts too |
13:54.15 | Crofton|road | Tartarus: early for you? |
13:54.17 | eFfeM_work | <PROTECTED> |
13:54.57 | Tartarus | Crofton|road, not since my son decided 0600-0630 is his getting up time |
13:55.19 | Tartarus | and he's still too young to read a clock :( |
13:55.42 | florian | Tartarus: This problem sounds familiar :-) |
13:55.48 | Crofton|road | is cursing noisy hotles |
13:55.52 | Crofton|road | hotels |
13:59.32 | eFfeM_work | JaMa: patch created, retested that it patches ok for all versions, don't have a nios tree handy to build it |
13:59.38 | eFfeM_work | if ok, please ack and I'll push it |
13:59.48 | eFfeM_work | patch is already send to ML |
14:00.37 | *** join/#oe dth_ntb (~dth@212.23.103.14) |
14:07.37 | pb_ | RP: are we due to have a TSC meeting today? |
14:07.45 | pb_ | loses track of which day is which |
14:13.47 | *** part/#oe mrj10 (~mrj10@63.252.64.254) |
14:15.50 | *** join/#oe atiti (~atiti@port492.ds1-bav.adsl.cybercity.dk) |
14:24.23 | sakoman_ | gm |
14:24.49 | sakoman_ | it seems commit b35109935bdb9e18671456a8c2e404a0c5556c0e breaks all images that include task-native-sdk |
14:26.00 | sakoman_ | was it intentional to change the name of the package generated? |
14:26.22 | Tartarus | kergoth? |
14:47.56 | mckoan | a Debian based Host PC is no longer valid choice to build OE ? |
14:48.30 | JaMa | due git without curl? |
14:48.32 | ericben | mckoan: works fine here |
14:48.45 | mckoan | JaMa: yes |
14:48.50 | JaMa | just remove ASSUME_PROVIDED git-native from your config I guess |
14:49.44 | JaMa | and then build git-native first with -b (because otherwise it will fail to build due to git) |
14:50.13 | mckoan | JaMa: and in this case bitbake create git and use it instead of the host provided? |
14:50.46 | JaMa | y |
14:54.52 | mckoan | funny http://tinderbox.openembedded.net/packages/985559/ |
14:54.54 | kergoth_ | sakoman_: hmm, i built one with that in fine, and compared the testlab results before and after to make sure the images were the same, maybe i messed up the test somehow |
14:55.00 | kergoth_ | sakoman_: what's the behavior? |
14:55.21 | *** join/#oe GNUtoo|laptop (~gnutoo@95.232.144.102) |
14:56.18 | sakoman_ | kergoth_: the commit removes: RPROVIDES_${PN} = "task-native-sdk" |
14:56.40 | sakoman_ | so any image that includes task-native-sdk fails due to no provider |
14:57.24 | kergoth_ | not seeing what you mean. the images that want it don't include task-native-sdk.inc, they add task-native-sdk to RDEPENDS, and task-native-sdk.bb produces a task-native-sdk package.. |
14:57.42 | kergoth_ | shrugs, can easily add it back |
14:57.56 | mckoan | ericben: works on you ride with Lenny 64bit? |
14:58.02 | kergoth_ | nothing in the current oe tree seems to behave the way you describe, as far as i can see |
14:58.11 | mckoan | ericben: s/ride/side |
14:58.44 | sakoman_ | kergoth_: note the subtle difference between task-sdk-native and task-native-sdk -- theold recipe was named the former, but produced the latter |
14:58.44 | kergoth_ | oh, i'm blind |
14:58.46 | kergoth_ | nods |
14:58.56 | kergoth_ | why the hell are we doing that, again? |
14:59.12 | kergoth_ | mutters |
14:59.17 | sakoman_ | I have no freakin' clue -- I've always found it bizzare and confusing |
14:59.25 | sakoman_ | but I just lived with it |
15:00.03 | kergoth_ | well, i'll bring back the rprovides for now |
15:00.07 | kergoth_ | we can fix the thing after the release |
15:00.20 | kergoth_ | well, the rprovides is probably good either way |
15:00.24 | kergoth_ | but the recipes should get a rename :) |
15:00.30 | sakoman_ | yup, I agree |
15:00.55 | sakoman_ | the -native at the end is confusing at best, and liekly wrong since it isn't a native package |
15:01.08 | kergoth_ | clearly you aren't the only one confused by this, since i got screwed up by it too :) |
15:01.29 | sakoman_ | I've had a gazillion gumstix customers ask me about it too |
15:01.39 | sakoman_ | it is definitely a faq |
15:02.56 | kergoth_ | k, fixed, thanks for spotting it |
15:03.43 | ericben | mckoan: I'm on a debian sid 64bits |
15:03.53 | CIA-71 | 03Chris Larson <chris_larson@mentor.com> 07master * rc4912d6abf 10openembedded.git/recipes/tasks/task-sdk-native.inc: |
15:03.54 | CIA-71 | task-sdk-native: resurrect RPROVIDES_${PN} |
15:03.54 | CIA-71 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
15:04.06 | mckoan | ericben: I suppose that sid has a newer git :-( |
15:04.17 | ericben | mckoan: Version: 1:1.7.2.3-2 |
15:04.26 | CIA-71 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07master * ra2820f8fd2 10openembedded.git/recipes/xorg-lib/ (8 files in 5 dirs): (log message trimmed) |
15:04.26 | CIA-71 | libX11: patch configure.ac so a nios2 system is not seen as an os2 system. |
15:04.26 | CIA-71 | The OS/2 platform requires some utility functions as well as having a non-32 bit wchar_t. Fix the configure check so that it doesn't also affect the nios2 cpu, which wouldn't influence these operating system issues. |
15:04.26 | CIA-71 | This is already accepted upstream and will be in 1.4 |
15:04.27 | CIA-71 | http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=affc2488a7f2660a74dc8354fc3e0bff2c4f879c |
15:04.27 | CIA-71 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
15:04.28 | CIA-71 | Acked-by: Martin Jansa <Martin.Jansa@gmail.com> |
15:04.37 | CIA-71 | 03Chris Larson <chris_larson@mentor.com> 07master * rc59070a06b 10openembedded.git/recipes/tasks/task-sdk-native.inc: |
15:04.37 | CIA-71 | task-sdk-native: forgot to bump INC_PR |
15:04.37 | CIA-71 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
15:04.37 | eFfeM_work | JaMa: thanks for the ack |
15:04.42 | JaMa|Off | yw |
15:05.19 | eFfeM_work | figured as it was identical to the upstream patch an ack from you alone is ok |
15:05.22 | ericben | kergoth_: hi, what do you think about the patch I send concerning amend.bbclass ? |
15:05.25 | eFfeM_work | would like to get this in the weekly build |
15:05.54 | Tartarus | When are testing tags made again? |
15:06.16 | Tartarus | would like to see sane-toolchain + powerpc work again :) |
15:06.21 | ericben | Tartarus: friday I think |
15:06.37 | mckoan | ericben: on Lenny is git version 1.6.3.3 |
15:06.44 | eFfeM_work | Tartarus: thursday, i think 5pm but not sure which TZ (probably EST or PST) |
15:06.51 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
15:07.01 | Tartarus | ok, a little time then, thanks |
15:07.06 | *** join/#oe mickey|office (~Mickey@openmoko/coreteam/mickey) |
15:07.15 | mckoan | ericben: and bitbake -b git-native fails |
15:07.34 | mckoan | ~curse git-native |
15:07.34 | ibot | May the fleas of a thousand camels infest your most sensitive regions, git-native ! |
15:07.37 | kergoth_ | ericben: the concept is good, but I think the logic of how MULTIMACH_ARCH is set is slightly more complex than that. Your patch won't catch the case where PACKAGE_ARCH_<pkg> is set to MACHINE_ARCH. See lines 58 through 89 in base.bbclass. We should likely shift that either out of an anonymous python function, or move that logic into lib/oe/ or a def'd python function, so we can call it from amend.bbclass as well |
15:08.50 | pb_ | hi kergoth |
15:08.58 | kergoth_ | hey pb_, how's it going? |
15:09.00 | ericben | kergoth_: OK I took inspiration from base.bbclass but didn't see all that. I'll try to update the patch. |
15:09.21 | *** join/#oe woglinde (~henning@p5DDC2F07.dip.t-dialin.net) |
15:09.26 | pb_ | kergoth_: yeah, good. cold and wet here nowadays, and starts getting dark at about 3pm, but fine apart from that :-) |
15:09.27 | kergoth_ | ericben: don't duplicate the code, please, make it common instead, or change it to not use anonymous python (e.g. MULTIMACH_ARCH = "${@get_multimach_arch(d)}" |
15:09.32 | kergoth_ | pb_: hehe |
15:09.33 | woglinde | hi |
15:09.49 | kergoth_ | its lovely here, finally in the 70s(F) during the day, best part of being in arizona |
15:09.51 | pb_ | kergoth_: are you expecting us to have a tsc meeting this morning? I can't quite remember what we agreed. |
15:10.15 | kergoth_ | i can't either -- i don't think i updated the meeting invite to match, so i get no reminders now |
15:10.18 | kergoth_ | heh |
15:10.31 | woglinde | *g* |
15:10.39 | Tartarus | mckoan: Is there perhaps a new git subpackage yuoi need to install from debian? |
15:10.46 | Tartarus | s/yuoi/you/ |
15:14.10 | mickey|office | i think we agreed to meet, but if there's nothing to discuss, we can make it end shortly |
15:14.26 | pb_ | mickey|office: ok, very good |
15:16.09 | mckoan | Tartarus: seems not |
15:18.05 | *** join/#oe xobs (~smc@cm152.psi156.maxonline.com.sg) |
15:18.51 | Tartarus | mckoan: perhaps it's a debian bug then? It looks like git ls-remote isn't functional |
15:20.07 | *** join/#oe mrj10 (~mrj10@mjlap.crhc.uiuc.edu) |
15:20.55 | *** part/#oe mrj10 (~mrj10@mjlap.crhc.uiuc.edu) |
15:21.43 | *** part/#oe screwgoth (~raseel@122.170.63.153) |
15:22.32 | mckoan | Tartarus: everything worked smoothly unilt 2nd November, must be something new and untested in OE |
15:23.38 | Tartarus | mckoan: Are you sure debian didn't update their git package since? |
15:23.39 | mickey|office | RP: ping? |
15:23.41 | Tartarus | That comes from bitbake |
15:23.51 | kergoth_ | mickey|office: does https://github.com/kergoth/bitbake/compare/master...parallel-parsing-prep seem sane to you? I'm trying to do some refactoring to make it easier to parallelize the parsing, so i can hand off a filename and get back the recipe info to be added to the cache and dep info, rather than having all this shared state |
15:24.14 | mckoan | Tartarus: and because seems that I'm the only one building OE on Lenny 64 I argue that who introduced the problem use a different distro |
15:24.37 | Tartarus | mckoan: Well, try this |
15:24.40 | Tartarus | do a ... |
15:24.51 | mickey|office | kergoth_: I'll take a look when I have a chance. |
15:25.07 | Tartarus | git ls-remote http://git.senfdax.de/git/literki master |
15:25.17 | kergoth_ | mickey|office: k, no rush, there's a shortage of python-fu in OE and Mentor, hard to get comments :) |
15:25.27 | mickey|office | *nod* i can imagine |
15:25.37 | mickey|office | i finally got around to writing some python again |
15:25.45 | mickey|office | after being buried in Vala and Objective-C for years |
15:25.48 | kergoth_ | hehe |
15:25.50 | kergoth_ | ncie |
15:25.52 | Tartarus | mckoan: THat's the command that's making that error and the man page for ls-remote says that's valid syntax, i think :) |
15:26.14 | mickey|office | i still have to learn python3 though, can't motivate myself, since there's too few libraries supporting it yet |
15:26.32 | mckoan | Tartarus: that command in oe tree? |
15:26.49 | kergoth_ | yeah, i haven't messed with it much either, though i really want to, particularly the io changes |
15:26.59 | mickey|office | yep |
15:27.03 | kergoth_ | i did start a branch in bitbake and ran some 2to3 fixers against it, thats about it :) |
15:27.05 | Tartarus | mckoan: That's the command OE is having bitbake execute |
15:27.11 | Tartarus | mckoan: And it's a normal git command |
15:27.12 | mickey|office | i guess by mid 2011 it should get better |
15:27.16 | mickey|office | people are slowly adopting it |
15:27.20 | Tartarus | So have debian's git try and do it |
15:27.31 | Tartarus | or any other command in the git ls-remote man page |
15:27.49 | kergoth_ | OE doesn't even technically require 2.[56] yet :| |
15:27.56 | mckoan | Tartarus: 16:35 koan@quad:openembedded$ git ls-remote http://git.senfdax.de/git/literki master |
15:28.00 | mckoan | error: git was compiled without libcurl support. |
15:28.02 | mckoan | Segmentation fault |
15:28.04 | kergoth_ | ouch |
15:28.09 | Tartarus | mckoan: There you have it, debian bug |
15:28.41 | Tartarus | I bet git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc also does that :) |
15:28.42 | mckoan | damn! |
15:28.43 | Tartarus | taken from the man page |
15:29.34 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
15:29.42 | kergoth_ | wonder if i could talk bitbake into running a 2to3 against our python in the metadata automatically ;) not that it covers everything, but.. |
15:29.50 | kergoth_ | hey cminyard |
15:29.59 | cminyard | morning kergoth_ |
15:30.30 | mckoan | Tartarus: thx anyway, I'll upgrade to sid |
15:31.01 | kergoth_ | mckoan: i'm new to the conversation, but what's the issue with git-native? |
15:31.27 | Tartarus | mckoan: Just file a bug w/ debian |
15:31.36 | Tartarus | That's pretty clearly something that got broken :) |
15:32.18 | mckoan | kergoth_: hi, see ML topic "16:24 < mickey|office> kergoth_: I'll take a look when I have a chance. |
15:32.35 | mckoan | kergoth_: hi, see ML topic "Error: git was compiled without libcurl support" |
15:33.01 | kergoth_ | ah |
15:34.15 | mckoan | goes back to mainstone build |
15:34.35 | *** join/#oe dijenerate (~dijenerat@65.48.150.197) |
15:37.13 | obi | the debian policy manual recommends using "Breaks" in addition to "Replaces" when moving a file to another package. how closely do we want to follow the debian policy? how about introducing an RBREAKS variable? |
15:37.27 | obi | see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts and http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces |
15:37.37 | kergoth_ | heh, does opkg support that? :) |
15:37.53 | obi | that would become part of the introduction of the new variable, i guess |
15:39.27 | kergoth_ | well, worst case the var wouldn't be used by the package managers that don't support it, which is how we've been doing it, as far as i know |
15:39.38 | kergoth_ | we have rpm as well, and there's no way everything is going to be supported by them all |
15:41.59 | obi | i guess i'll prepare a patch to get some feedback from the mailing list, then |
15:42.09 | Tartarus | And yocto has a lot of rpm work that would be good to get |
15:42.19 | Tartarus | If possible since it requires pseudo and all that |
15:42.28 | *** join/#oe chouimat (~mathieu@kde/developer/chouinard) |
15:45.58 | Radioo | Hello, someone has an idea how to fix this build error with OE: http://pastebin.com/xhZmvqQs ? |
15:46.49 | kergoth_ | obi: good plan |
15:47.53 | *** join/#oe methril_work (~methril@201.35.65.90) |
15:48.18 | pb_ | what are the semantics of Breaks? I'm not familiar with that field. |
15:48.37 | pb_ | I'm fairly sure that opkg doesn't support it today but, of course, it could be made to. |
15:50.49 | obi | it indicates that the replaced package must be upgraded to continue to work, e.g. after the replacing package gets removed |
15:50.56 | obi | http://www.debian.org/doc/debian-policy/footnotes.html#f46 |
15:51.05 | *** join/#oe jolt (~jolt@p5B3DDA82.dip.t-dialin.net) |
15:51.58 | *** join/#oe Jay7 (jay@78-106-240-238.broadband.corbina.ru) |
15:58.04 | pb_ | RP: ping |
16:16.53 | *** join/#oe methril_work (~methril@201.35.65.90) |
16:23.35 | *** join/#oe atiti (~atiti@0103ds1-vir.0.fullrate.dk) |
16:30.12 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
16:30.12 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
16:31.43 | *** join/#oe henry1 (~honzhan2@nat/cisco/x-jifqfaufiwooytjp) |
16:32.46 | *** join/#oe methril_work (~methril@201.35.65.90) |
16:35.06 | kergoth_ | damnit, __BB_DONT_PARSE seems to be biting me in the ass |
16:35.08 | kergoth_ | hrm |
16:36.16 | kergoth_ | oh hell, i think i see it |
16:36.17 | kergoth_ | hmm |
16:41.33 | *** join/#oe stefan_schmidt (~stefan@p5B035F8A.dip.t-dialin.net) |
16:56.32 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
16:56.35 | *** join/#oe jolt__ (~jolt@p5B3DDA82.dip.t-dialin.net) |
16:59.32 | Crofton | anyone know where people talk about the features/improvements to gcc that come from linaro? |
17:00.37 | woglinde | on the linaro ml? |
17:01.21 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
17:05.53 | *** join/#oe rednul (~rednul@host-174-45-250-246.bln-mt.client.bresnan.net) |
17:06.18 | mckoan | have a nice rest of the day |
17:10.58 | obi | hi woglinde! could you please comment on this patch: http://patchwork.openembedded.org/patch/3427/ - git says that you've changed this file (pkgconfig.bbclass) before. ;-) |
17:11.42 | *** join/#oe eFfeM (~frans@j200125.upc-j.chello.nl) |
17:14.03 | *** join/#oe Martin__B (~martin@a89-183-11-169.net-htp.de) |
17:16.01 | eFfeM | gm |
17:17.14 | pb_ | obi: that patch looks sensible to me |
17:20.09 | obi | I'd need some one or two acks on the mailing list and a decision when to apply it (before or after the release) ... and finally someone to apply it for me, because my git write access still is non-functional |
17:22.20 | woglinde | hm |
17:22.23 | *** join/#oe blindvt (~bf@85-127-155-31.dynamic.xdsl-line.inode.at) |
17:22.40 | woglinde | I am going home now |
17:22.43 | woglinde | till later |
17:33.21 | *** join/#oe toi (~toi@d54C2AA76.access.telenet.be) |
17:41.39 | *** join/#oe methril_work (~methril@201.35.65.90) |
17:43.00 | blindvt | hi |
17:44.35 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
17:49.10 | *** join/#oe Radiooo (~Radio@port-87-193-237-134.static.qsc.de) |
17:50.49 | blindvt | eFfeM_work, khem, which ones of those patches for uClibc++ are not in master ATM? Given the fact that uClibc++ is not very volatile a target, i'd recommend to use the master and not some old tarball |
17:55.10 | hufnus_cicq | ISON |
17:57.34 | *** join/#oe dth_ntb (~dth@a89-183-11-169.net-htp.de) |
18:00.35 | *** join/#oe toi (~toi@d54C2AA76.access.telenet.be) |
18:34.36 | khem | Crofton: gcc improvements are mainly on linaro mailing lists and the WG meeting minutes |
18:34.52 | Crofton | are they online? |
18:34.56 | khem | Crofton: any specific question ? I can answer too |
18:35.07 | khem | Crofton: yes. See linaro.org |
18:35.31 | Crofton | I just want some stuff to look over |
18:35.43 | *** join/#oe DJWillis (djwillis@cpc3-bath5-2-0-cust220.aztw.cable.virginmedia.com) |
18:39.36 | khem | Crofton: ok |
18:40.01 | khem | actually you wont find vigourous discussions compared to the number of patches but you can get some idea |
18:40.09 | khem | I personally look at the patches what they do |
18:42.24 | Crofton | I have an application that has some events I would like to use to do page up/down |
18:42.38 | khem | k |
18:42.46 | Crofton | any thoughts on how I can have user space simulate those key presses ? |
18:43.12 | Crofton | anyone can answer :) |
18:43.41 | stefan_schmidt | Crofton: libfakekey? |
18:43.43 | khem | Crofton: if you are using some GUI framework it should have such events |
18:43.57 | stefan_schmidt | Crofton: its used for virtual keyboards |
18:44.35 | Crofton | stefan_schmidt, sounds good |
18:44.46 | Crofton | this is on gnome built in OE |
18:45.17 | stefan_schmidt | Crofton: used from the matchbox keyboard and maybe also the E17 keyboard |
18:45.26 | stefan_schmidt | should not depend on to much gnome things. |
18:45.35 | stefan_schmidt | But its years since I looked into it |
18:45.46 | Crofton | thanks, I'll look into this |
18:46.40 | *** join/#oe florian (~fuchs@sign-4d09417c.pool.mediaWays.net) |
18:46.40 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
18:46.43 | Crofton | ouoch, does svn.0-hand.com exist anymore |
18:47.18 | stefan_schmidt | Crofton: hmm, check git.o-hand |
18:48.56 | Crofton | the source mirror has it :) |
18:57.01 | *** join/#oe rednul (~rednul@host-174-45-250-246.bln-mt.client.bresnan.net) |
18:58.43 | *** join/#oe cazze (~pc@d54C04D68.access.telenet.be) |
18:58.51 | cazze | hi |
18:59.11 | cazze | i have problem compiling openssl-1.0.0a |
18:59.20 | cazze | it always fails in the app directory |
18:59.26 | cazze | is this a know problem? |
18:59.33 | cazze | is ther a solution? |
19:08.59 | *** join/#oe mw___ (3ff5f443@gateway/web/freenode/ip.63.245.244.67) |
19:09.02 | mw___ | michaelw |
19:10.09 | mw___ | i am having issues build the meta-toolchain-qte |
19:10.53 | mw___ | why is it trying to access my host machine native libraries? |
19:16.51 | blindvt | Crofton, just send a key press and key release event yourself, no? think: http://paste.debian.net/100067/ |
19:17.19 | blindvt | Crofton, (modulo typos and eventually missing bits) |
19:17.41 | Crofton | :) |
19:17.55 | Crofton | thanks, forwarding all these to the guy that needs to make it work |
19:18.01 | Crofton | he's messing in python atm |
19:19.05 | blindvt | Crofton, well, i bet there's a python wrapper for Xlib too. Same thing there: If you need an event, heck, just send one ;) |
19:21.07 | *** join/#oe kelvie_ (~kwong@s209-52-149-70.bc.hsia.telus.net) |
19:22.19 | *** join/#oe guufy (~Guufy@70-35-57-218.static.wiline.com) |
19:22.47 | blindvt | Crofton, oops, i forgot to send the release with a KeyReleaseMask. But he'll get the idea.. |
19:22.55 | blindvt | whatever |
19:24.05 | Jay7 | Packaged contents of kernel into /storage/oe/testbuilder/build/minimal/armv7/deploy/ipk/efikamx/kernel_2.6.31-r0_efikamx.ipk |
19:24.07 | Jay7 | kernel-2.6.31.12-ER1 |
19:24.08 | Jay7 | *** Error: Package name contains illegal characters, (other than [a-z0-9.+-]) |
19:24.13 | Tartarus | yeah |
19:24.16 | Jay7 | khem: no good :( |
19:24.18 | Tartarus | Didn't someone else hit that yesterday? |
19:24.25 | kergoth_ | yep |
19:24.31 | Tartarus | Can't do ER in your version |
19:24.32 | kergoth_ | khem was talking about it |
19:24.37 | *** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
19:25.49 | Jay7 | NOTE: oestats: error sending task, disabling stats |
19:25.51 | Tartarus | I guess upstream patches or the defconfig adds -ER1 to LOCALVERSION |
19:25.54 | Jay7 | eh.. |
19:28.03 | Crofton | blindvt, sounds like he has it going in python |
19:33.45 | kergoth_ | khem: regarding the release, the TSC covered that today, might want to wait for pb_'s mail |
19:35.13 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
19:35.27 | khem | Jay7: yeah I will fix it |
19:35.37 | khem | Jay7: I have to patch the kernel version string |
19:35.47 | khem | kergoth_: so whats the direction? |
19:36.04 | khem | kergoth_: do we intend to branch a release ? |
19:36.13 | Jay7 | khem: if possible do it before next testing branch update :) |
19:36.23 | khem | Jay7: yes I will |
19:37.33 | kergoth_ | khem: yes, branch off for the release, then tag that branch after a period of time wherein cherry picking will occur for any fixes that need to go in the release |
19:37.43 | kergoth_ | khem: wait for the official word, though. |
19:38.06 | khem | hmmm. who will maintain the branch |
19:38.12 | khem | do we have volunteers |
19:38.17 | khem | or is it one of thing |
19:38.19 | Crofton | maintenance should be a distro issue, not an official OE task |
19:38.34 | khem | ok so we branch out |
19:38.41 | Crofton | otherwise we run into the problem khem describes |
19:38.49 | khem | and release from there and distro's can then backport |
19:38.56 | khem | so essentially like stable/2009 |
19:39.00 | Crofton | yeah |
19:39.10 | Crofton | but what OE publishes is the starting point |
19:39.55 | kergoth_ | we're not talking about a long lived branch here. |
19:40.02 | khem | I dont know how many folks will deliver for stabilizing release branch |
19:40.02 | kergoth_ | the branch is for any stabilization *before* the release |
19:40.08 | kergoth_ | the release itself is a tag from that branch |
19:40.13 | kergoth_ | not a release branch after that |
19:40.25 | khem | kergoth_: you release from a tag or not |
19:40.30 | Jay7 | what is purpose of testing branch then? |
19:40.31 | khem | once you branched thats it |
19:40.36 | kergoth_ | ? |
19:40.53 | khem | kergoth_: I mean that becomes the maintainance thing |
19:40.58 | kergoth_ | no |
19:41.06 | khem | but I think we dont have that much man power seriously |
19:41.09 | kergoth_ | there will not be a maintainance branch for the release, no fixes go in after the release |
19:41.19 | Crofton | basically, we need to try things and see what works well |
19:41.23 | Jay7 | seems we going to use freebsd release logic :) |
19:41.57 | Crofton | kergoth_, but there is no objection to a distro copying from the tag and maintianing it for their puroposeds |
19:42.01 | kergoth_ | the only reason for a branch at all is to give a bit of extra time to pull in any fixes between now and the release. if there aren't any, so be it, but master isn't going to be limited the way you described in the email |
19:42.03 | khem | kergoth_: OK sounds fine |
19:42.05 | kergoth_ | Crofton: right, exactly |
19:42.30 | khem | I see that the guy who is doing the release is the only one stabilizing |
19:42.31 | blindvt | kergoth_, i have a few pythonic hunks for bb fetchers that i'd like to push if it's ok for you. May i send them to you directly, the list or point'n click url? |
19:42.36 | kergoth_ | if the release person wants to go based on testing, they're free to do so |
19:42.44 | kergoth_ | khem: right, thats how i see it |
19:43.00 | Crofton | some people REALLY like the current stable branch :) |
19:43.18 | Crofton | at ELCE we talked with a couple of atmel guys who find it really useful |
19:43.22 | kergoth_ | blindvt: direct email is less convenient due to having to get the patches out of my gmail account, there's no pw-am.sh for gmail ;) |
19:43.31 | Crofton | largely becuase it is very slow to change :) |
19:43.54 | khem | kergoth_: I think we wont muster enough people and time for release. |
19:43.57 | kergoth_ | the problem with a long lived stable branch is its nearly impossible to keep up with and review all the commits that do go into master |
19:44.09 | kergoth_ | unless master gets merged to it periodically or something, e.g. git's maint branch |
19:44.15 | khem | kergoth_: my idea is a tag on master |
19:44.21 | khem | every six months |
19:44.56 | kergoth_ | like i said, that's fine with me, the only decision that was made was that master will not be frozen, if shit breaks there and you can't release from it, that's on you |
19:44.57 | khem | but branch is fine too. |
19:45.03 | kergoth_ | beyond that, whatever :) |
19:45.33 | kergoth_ | i think we need to sit down and establish a documented process/workflow for our branches and tags and releases |
19:45.41 | khem | yes |
19:45.41 | kergoth_ | right now things are a bit too haphazard |
19:45.44 | Jay7 | +1 |
19:46.00 | khem | I think branch is fine. As long as devs help out on release |
19:46.09 | kergoth_ | there are many great workflows out there that other projects use, we may want to do something based on one of those -- and most of those are based on general configuration management patterns |
19:46.19 | khem | my only motivation to carve it out of master is the amount of developer base using it |
19:46.34 | blindvt | kergoth_, http://uclibc.org/~aldot/bitbake/20101117-1606/ |
19:46.57 | khem | if devs come onboard with testing and helping out a to be released branch no problems infact its even better |
19:47.03 | kergoth_ | I'd personally rather like to see something like what git does for their project, with 'next' and potentially 'pu' and all |
19:47.26 | khem | well our master = next |
19:48.07 | khem | but I think the release branch will come into being sooner or later even if we tag master |
19:48.21 | kergoth_ | which is the problem, really. features dont get integrated together and tested as a whole other than in master itself right now |
19:48.22 | khem | because I expect some heavy use of the release which might need bug fixes |
19:48.25 | kergoth_ | which is just asking for problems |
19:48.26 | otavio | Crofton: I do think stable is useful and we depend on it here at O.S. Systems |
19:48.34 | khem | and some distro maintainers backport stuff |
19:48.42 | Crofton | otavio, thanks |
19:48.52 | otavio | Crofton: the only problem we have is a "merge point" to "dev" |
19:49.01 | Crofton | we get little feedback, bu that is good :) |
19:49.01 | kergoth_ | blindvt: oh good, suppports always got on my nerves :) |
19:49.23 | otavio | Crofton: we would need a way to merge to "next stable" |
19:49.42 | kergoth_ | blindvt: regarding strip leading slashes, OE works around that exact same issue -- this makes me think we need to move lib/oe/path.py:join into bb.utils. |
19:50.02 | khem | so I guess what we will do is create the release-2010.12 branch |
19:50.21 | khem | and call out for devs to pound on it |
19:50.28 | eFfeM | blindvt it is probably a good idea to go for the latest version |
19:50.32 | eFfeM | of uclibc++ |
19:50.37 | eFfeM | didn't really consider that |
19:50.39 | khem | may be using the testing matrix |
19:50.39 | blindvt | kergoth_, bummer, i totally forgot about oe.path. Yea, perhaps that's a good idea |
19:50.51 | kergoth_ | blindvt: second, ud.parm.get('md5sum', None) -> None is the default for the second argument, you can just ud.parm.get('md5sum') |
19:51.01 | eFfeM | guess the patches are not in htat version either, there are really only a few commits since the 0.2.2. release |
19:51.09 | eFfeM | (5-10 iirc) |
19:51.21 | otavio | khem: if there's any "new" release (stable or whatever) please merge it back into dev from time to time |
19:51.30 | otavio | khem: so we have "merge points" at it |
19:51.34 | khem | otavio: it wont be merged |
19:51.43 | khem | otavio: patched should be always backported |
19:51.51 | khem | to it via master imo |
19:51.51 | otavio | khem: so it will always be a nightmare |
19:52.07 | Jay7 | freebsd or pkgsrc release process is alike |
19:52.13 | khem | otavio: and 6 months down the line we will have next release |
19:52.20 | kergoth_ | blindvt: also you have a remnant commented out line in fetch/svn.py, first hunk in the last patch |
19:52.20 | Crofton | otavio, that is hard problem due to core changes in dev |
19:52.21 | khem | and then this release is decommissioned |
19:52.22 | Jay7 | pkgsrc does release quarterly |
19:52.27 | kergoth_ | blindvt: other than that, they look sane to me |
19:52.53 | Jay7 | freebsd have stable and current branches (like our) |
19:53.10 | blindvt | eFfeM, garrett didn't do any release in a long time, so i'd really go for master. I admit that i didn't recently try to use it instead of libstdc++-v3 so i'm not current of possibly missing features. That said, we will only fix trunk and journal stuff there so that's what folks should be using for now |
19:53.47 | Jay7 | I like pkgsrc scheme |
19:54.03 | blindvt | kergoth_, yes: '#logger.warn("You should switch to SRCREV")' |
19:54.05 | kergoth_ | blindvt: its also possible we should consider breaking up bb.utils. oe's module is nicely arranged, and move some other things into bitbake, in the long term, but don't bother with that now, i'd suggest just adding oe's join to bb.utils |
19:54.06 | Jay7 | split branch quarterly, stabilize it and announce release |
19:54.12 | kergoth_ | s/module/package/ |
19:54.16 | Jay7 | then return to work on master |
19:54.32 | Jay7 | release branches are subject to security updates only |
19:54.38 | blindvt | kergoth_, i wasn't sure if the comment above that now added comment was still true so i ment to suggest the requested warning. |
19:54.45 | kergoth_ | ah |
19:55.08 | otavio | Crofton: no related stuff |
19:55.09 | kergoth_ | probably not a bad idea |
19:55.17 | blindvt | kergoth_, i didn't runtime test anything of that and i didn't want to spit out odd/outdated/misplaced warnings |
19:55.19 | otavio | Crofton: if backports are done into release |
19:55.23 | kergoth_ | nods |
19:55.31 | otavio | Crofton: release ought to "merge" fine into dev |
19:55.45 | kergoth_ | blindvt: mind looking over a bit of python for me? finding folks with python-fu to review my bitbake changes is like pulling teeth |
19:55.48 | otavio | Crofton: and merging it into dev provides an upgrade path for next stable |
19:55.51 | kergoth_ | heh |
19:55.52 | Crofton | this is why I see people developing their own concpet of "stable" |
19:56.38 | otavio | Crofton: for us, for example, move to next OE is a nightmare since we have too many conflicts to deal with |
19:56.41 | blindvt | kergoth_, didn't runtime-test anything as in all of those whole series (but i'm rather confident that it should work just fine, i think) |
19:56.41 | khem | otavio: This release we will should try to always commit to master and then backport to release branch thats upto disto maintainers |
19:56.45 | eFfeM | khem, please see my reply on the uclibc++ mail, the error messages are in the original mail and in the reply |
19:56.57 | khem | if there is a patch thats only needed on release and not on master then thats fine |
19:57.06 | khem | because the patch is dead anyway |
19:57.10 | otavio | khem: right but only doing this doesn't make it work |
19:57.18 | otavio | khem: we need to merge release back into master |
19:57.30 | khem | otavio: I dont get it |
19:57.38 | otavio | khem: since master will contain all changes of release it will just work |
19:57.41 | Jay7 | we can just release more frequently |
19:57.43 | JaMa | neither do I |
19:57.47 | Jay7 | fire and forget :) |
19:57.48 | khem | if you branch out and all commits to this branch come via master what do u need to merge back ? |
19:57.55 | blindvt | kergoth_, ok, thanks. So i'll push those and see if turning on that warning makes sense the next time i build oe and then commit that warning on top |
19:58.12 | otavio | khem: OK... let me try to explain |
19:58.13 | khem | otavio: but master will have other shitload |
19:58.19 | khem | that can bite you in the ass |
19:58.19 | Jay7 | I see this is only way for OE at this time because nobody cares about stable |
19:58.25 | kergoth_ | blindvt: push after making the changes i proposed? :) |
19:58.33 | Crofton | Jay7, that is not true |
19:58.56 | kergoth_ | blindvt: take a look at https://github.com/kergoth/bitbake/compare/master...parallel-parsing-prep, thoughts? |
19:59.01 | khem | Jay7: only way to enlarge userbase is to have releases |
19:59.15 | otavio | Let me try to make it clear. |
19:59.22 | Jay7 | khem: yes, sure |
19:59.25 | otavio | OE releases 2010.12 |
19:59.39 | otavio | <PROTECTED> |
19:59.50 | otavio | <PROTECTED> |
19:59.52 | khem | Crofton: yes thats true |
20:00.02 | otavio | <PROTECTED> |
20:00.09 | *** join/#oe kristoffer (~kristoffe@c-a3dee555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
20:00.13 | Crofton | I have received very positive feedback from suers |
20:00.24 | otavio | <PROTECTED> |
20:00.43 | Jay7 | otavio: how to deal with core changes? |
20:00.44 | Crofton | where users is defined as people doing work with the output of OE |
20:00.50 | blindvt | kergoth_, which proposed changes? 1) enable the warning -- scheduled for the next oe build. 2) what? |
20:01.04 | Jay7 | e.g. changing required bitbake (and python) versions |
20:01.19 | Jay7 | or changing metadata behaviour like new staging |
20:01.25 | kergoth_ | blindvt: add oe.path.join to bb.utils and use that, drop the unnecessary ", None" in that ud.parm.get for md5sum |
20:01.39 | khem | otavio: why should release is merged back into master |
20:01.42 | JaMa | otavio: so every commit which was cherry-picked to release will be twice on master? |
20:01.45 | Jay7 | release is point, not branch :) |
20:01.59 | blindvt | kergoth_, k |
20:02.26 | JaMa | otavio: with 2 different hashes and whoever merged release to master will resolve possible conflict for you? instead resolving all together much later when there is new release? |
20:02.58 | otavio | JaMa: yes. Or we commit into release and merge it into master |
20:02.59 | Jay7 | we should define 'release' and 'branch from release was made' |
20:03.04 | Jay7 | *from which |
20:03.24 | Jay7 | thats are different things.. |
20:03.29 | JaMa | otavio: probably first to master to provide some testing before cherry-picking to release |
20:03.41 | blindvt | kergoth_, i kept the md5sum None for better readability. In fact i had it out and put it back in in an odd attempt to help other people to understand the code ;) |
20:03.50 | otavio | usually maintainence branches receive fixes that are merged into development one when done |
20:04.05 | otavio | JaMa: but then there's no path to upgrade to master again |
20:04.11 | kergoth_ | I think dict's "get" is pretty well known, if anything itd be the existance of the second argument that's less well known |
20:04.21 | khem | otavio: no merge into release it gets the patches from master that way we make sure that all fixes go into master |
20:04.28 | khem | and are there in next release |
20:04.34 | otavio | JaMa: if you try: git merge stable/2009 into master you'll see the nightmare it is |
20:04.38 | kergoth_ | uses it all the time to avoid having to catch a KeyError or check for existence first |
20:04.47 | blindvt | kergoth_, indeed |
20:04.50 | khem | then they are cherry picked into release even though the fix is only for release |
20:05.44 | khem | otavio: there has to be some time length of maintainance we can not keep a separate brach for that long syncing happily with master |
20:05.50 | khem | OE changes frequently |
20:06.17 | khem | and sometimes changes are fundamental |
20:06.24 | otavio | khem: how do you suggest to a company to "fork" from main OE and have an upgrade path for next release then? |
20:06.34 | JaMa | otavio: why not cherry-pick commits from your branch to new "release" and resolve only those (with needed changes due different core)? |
20:06.45 | kergoth_ | I'd suggest a week or two at absolute most for the existence of the release branch, then tag, possibly merge to master, and delete the branch |
20:06.51 | blindvt | kergoth_, quick style question about import. Do you prefer CSV imports (os, re) or one per line. What about potentially redundant imports -- if bb pulls in module_foo, and mod1 imports bb, should mod1 also import module_foo if it uses stuff from it, just to be sure? |
20:06.53 | khem | gives up and thinks just make the release happen and stop thinking beyond that |
20:07.14 | kergoth_ | blindvt: iirc PEP8 advises one import per line |
20:07.20 | obi | otavio: i think the "nightmare" comes from changing files for your fork and not submitting the changes for inclusion into master |
20:07.21 | khem | otavio: w.r.t. internal changes ? |
20:07.23 | kergoth_ | i'd say be explicit about what you're using, don't rely on indirect imports |
20:07.31 | obi | otavio: maybe using abb layer would help |
20:07.34 | khem | otavio: the next release will be another branch |
20:07.46 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
20:07.49 | khem | and it will have all fixes that were done to previous release |
20:07.57 | blindvt | kergoth_, k. Just asking since alot of spots rely on indirect imports of os.path (IIRC) |
20:08.00 | khem | so your next product can base of this branch |
20:08.36 | kergoth_ | blindvt: oh, i see what you mean |
20:08.45 | otavio | obi: partially yes. But not really. |
20:08.47 | kergoth_ | for that particular case, where the package imports one of its own modules, you can rely on that |
20:08.57 | kergoth_ | an import of just os will get you os.path |
20:09.06 | kergoth_ | now, if you only use os.path, nothing else in os, i'd say just import os.path |
20:09.15 | kergoth_ | imo anyway |
20:09.17 | khem | otavio: I guess you have to stabilize on a release |
20:09.25 | khem | and next release |
20:09.26 | blindvt | kergoth_, ok |
20:10.06 | kergoth_ | i think we need to avoid the 'from' imports as well, it causes problems with module reloading, which is something we may want to support in the future when we support a long lived bitbake server process |
20:10.16 | otavio | khem: but not using a git tree. Using a layer? |
20:10.25 | khem | otavio: its then upto you how long you wanna maintain a release branch, the fact that you make the patch work on master makes sure that the problem is fixed for next release |
20:10.29 | blindvt | kergoth_, one last thing: this one's still open (from earlier today): |
20:10.33 | blindvt | kergoth_, can we use bz2 or no compression at all (instead of .gz) for packing checkouts or do you think that doesn't make sense or won't be used? Just an idea.. |
20:10.44 | khem | otavio: yes layer is better |
20:10.56 | kergoth_ | blindvt: i think that should likely wait until the fetch revamp |
20:10.59 | otavio | khem: we use a git tree currently |
20:11.05 | khem | otavio: unfortunately there is no OE standard like ISO C standard that we comply to |
20:11.09 | kergoth_ | since we're looking to move unpack/fetch all into bitbake's new fetch module, so things like git can have a more intelligent unpack |
20:11.10 | otavio | needs to learn how to work with layers |
20:11.12 | khem | so things change |
20:11.20 | blindvt | kergoth_, i see |
20:11.30 | kergoth_ | the whole archival of scms may change entirely, or become optional just for mirroring purposes |
20:11.53 | khem | otavio: yeah layers can give you better view of minimizing the changes to OE metadata |
20:12.12 | otavio | khem: after the meeting can we talk about this ? |
20:12.13 | khem | and then when you upgrade to newer release you have to port forward your layers only in ideal case |
20:12.14 | blindvt | kergoth_, i'll have a look at your parallel-parsing-prep if i find the time |
20:12.21 | kergoth_ | blindvt: np, no rush |
20:12.27 | kergoth_ | just need a sanity check :) |
20:12.42 | kergoth_ | e.g. am i completely out of left field, or is this a real improvement to the code |
20:12.44 | blindvt | figured :) |
20:13.03 | *** join/#oe anarsoul (~anarsoul@80.249.95.238) |
20:13.20 | khem | otavio: which meeting ? |
20:13.42 | otavio | khem: well, I don't want to disturb asking questions now |
20:14.04 | khem | otavio: sure. |
20:15.16 | blindvt | kergoth_, did you, by chance, had time to poke at one of those 3 oe patchlets we talked about yesterday? (the redundant deps and, auto-depend native unpackers and the third one)? |
20:15.57 | blindvt | s/poke/look/ |
20:15.59 | kergoth_ | blindvt: i dropped the class changes and was able to build xz and xz-native fine on my machine and configuration, anyway |
20:16.05 | kergoth_ | i didn't dive any further than that, though |
20:16.21 | kergoth_ | has so many bitbake and oe trees/branches he's in real danger of forgetting where he was doing things |
20:16.36 | kergoth_ | https://gist.github.com/700677 |
20:16.38 | kergoth_ | heh |
20:17.44 | kergoth_ | meh |
20:17.45 | blindvt | i'm interrested in feature/typing! perhaps that one can fix my keyboard -- or myself for that matter :P |
20:17.51 | kergoth_ | hehe |
20:17.53 | kergoth_ | if only it meant that |
20:22.23 | blindvt | kergoth_, is it ok to handle that 'add oe.path.join to bb.utils' later and push the rest now? I'm accumulating too much noops in bitbake and way too many against oe |
20:22.54 | kergoth_ | feel free to push it with the strip slash bits now and revisit later if you want |
20:23.03 | blindvt | k. thanks |
20:23.03 | kergoth_ | i know how you feel |
20:23.05 | kergoth_ | np |
20:23.33 | kergoth_ | i've resorted to using topgit to manage integration branches, so i can do most of my builds on an integration branch that pulls in all the branches i have pending, and can update it all easily |
20:24.02 | blindvt | kergoth_, at least i can get rid of local stuff i accumulate in bb. That's a good start :) |
20:24.05 | kergoth_ | nods |
20:25.26 | blindvt | given the rate that i can trick khem into applying stuff to oe there's a long way to go, but hey |
20:25.59 | khem | blindvt: you just have to make less controversial patches :) |
20:26.28 | kergoth_ | i hate it when you put a ton of work into something, then send-email, and get no replies because nobody wants to touch whatever you're changing with a 10 foot pole :) |
20:27.05 | blindvt | khem, they're useful or make stuff work |
20:27.08 | Jay7 | autobuilder can solve this :) |
20:27.25 | Jay7 | at least check that your changes doesn't break building |
20:27.32 | kergoth_ | yeah |
20:27.55 | Jay7 | let's ask Amazon to donate cloud for OE :) |
20:27.59 | cazze | can somebody help me build openssl-1.0.0a? |
20:28.12 | cazze | i get errors in the app dir |
20:28.14 | Jay7 | then build some kind of autobuilder/tinderbox there :) |
20:28.45 | blindvt | khem, your master has fucked up ppc support because of bugs in gcc. I sent (i really hope i did when i'm bitching around like that now ;) a workaround to reinstate ppc and nothing happened. *shrug* |
20:28.55 | Jay7 | or even let's ask Intel/AMD directly for build farm :) |
20:29.34 | cbrake | with Ubuntu 10.10, make -j8 no longer pegs a i7 CPU. Does anyone know if anything has changed with recent versions of make? |
20:29.39 | khem | blindvt: ppc works fine in OE |
20:30.28 | *** join/#oe Jordinar (~Jord@77-20-67-155-dynip.superkabel.de) |
20:31.37 | Jay7 | I can add build request interface for my home machine |
20:31.45 | Jordinar | Has someone an idea what's wrong here with mtd-utils_1.3.1.bb - http://pastebin.com/xhZmvqQs ? |
20:31.45 | khem | cbrake: hmm interesting never heard that kind of issue |
20:31.48 | *** join/#oe pb__ (~pb@blundell.swaffham-prior.co.uk) |
20:31.57 | *** join/#oe zenlinuxPDX (~sgarman@li38-254.members.linode.com) |
20:31.58 | Jay7 | to allow build request queueing |
20:32.09 | khem | cazze: paste your issue somewhere |
20:33.45 | ericben | cbrake: here with PARALLEL=16 and BBTHREAD=4 the i7 gets quite loaded ;-) |
20:34.36 | khem | Jordinar: your objdir looks suspicious |
20:34.57 | blindvt | khem, qemuppc didn't build for me last time i tried. How did you build libstdc++-v3 without support for long-double-128? |
20:34.59 | khem | Jordinar: the issue is that the files are compiled for some other arch and are being linked into some other |
20:35.19 | khem | blindvt: well it build now |
20:35.36 | khem | blindvt: thre is ofcourse one patch from Tartarus that should go in |
20:35.46 | khem | which should happen once he fixes the comment |
20:35.57 | *** join/#oe mrj10 (~mrj10@mjlap.crhc.uiuc.edu) |
20:36.29 | *** part/#oe mrj10 (~mrj10@mjlap.crhc.uiuc.edu) |
20:36.41 | Jordinar | khem: Why is that so? I just picked a preconfigured machine without changing it and issued 'bitbake minimal-image' - or where could I fix that? |
20:37.13 | khem | Jordinar: what does your local.conf look like |
20:37.40 | blindvt | khem, micro-uclibc with current binutils and current gcc? Can you show me your conf? It didn't for me: http://paste.debian.net/100073/ |
20:37.45 | kergoth_ | hmm, would be nice if github let you add a description to a branch, or knew how to show .topmsg when using topgit |
20:38.23 | cbrake | hmm, even with -j16, top is showing only 50% on a kernel build. That is very odd. In the past -j8 pretty much used all CPU on a kernel build. |
20:38.37 | Jordinar | khem: that's all: http://pastebin.com/eCMnrzVg |
20:39.07 | khem | blindvt: except I use gcc 4.5 |
20:39.09 | *** join/#oe Martin_B (~martin@pool-21-67-198-89.dbd-ipconnect.net) |
20:39.11 | khem | and minimal-uclibc |
20:39.48 | Jay7 | cbrake: 1) may be you building something that just have no load for 16 threads; 2) may be some changes in kernel scheduler |
20:39.51 | JaMa | for me micro+eglibc didn't somehow stage stdio.h and eglibc-initial failed to do_configure bacause of it :/ |
20:40.08 | khem | Jordinar: you dont need to set TARGET_OS |
20:40.33 | khem | JaMa: since when ? |
20:40.48 | *** join/#oe Martin__B (~martin@pool-21-67-198-89.dbd-ipconnect.net) |
20:40.49 | khem | JaMa: I think some folks do use micro |
20:40.58 | khem | and dont see this |
20:41.07 | JaMa | no idea this was actually my first micro build (just to test that binconfig change I've sent to ML) |
20:41.36 | khem | blindvt: anyway take latest OE apply http://patchwork.openembedded.org/patch/3565/ and qemuppc should work |
20:41.57 | Jay7 | btw |
20:42.18 | Jay7 | khem: ack changes for sh3/4 or push it :) |
20:42.23 | khem | Jay7: you have my ack for that |
20:42.27 | blindvt | khem, yuck |
20:42.29 | JaMa | khem: I suspected my patch and then 6f5c792dd75746009e7a5994170cec05a92f0fdd, but even after reverting those 2 It still failed |
20:42.35 | Jay7 | ok, I'll push it then |
20:42.40 | Jordinar | khem: "you dont need to" -- meaning it's a problem if I do? I'm trying without that. Is a clean compile necessary then, so I have to remove the whole tmp dir? |
20:43.54 | khem | Jordinar: I think OE is overriding that for you |
20:43.59 | khem | so not an issue here |
20:44.35 | cazze | khem: http://pastebin.com/EJy08CmH |
20:44.52 | khem | Jordinar: but this path is fishy /home/radi/oe/build/minimal/mkfs.ubifs/crc16.o |
20:44.54 | Jordinar | khem: alright, mtd-utils still fails... bad, but thanks for your help |
20:45.19 | khem | Jordinar: how does it come to pick that object I wonder |
20:45.19 | *** join/#oe little_owl (~little_ow@5e011ddc.bb.sky.com) |
20:45.59 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
20:46.59 | Jordinar | khem: the only thing I can tell you is that this file exists ... there are several others in build/minimal --- all related to mtd-utils obviously |
20:47.03 | khem | cazze: it seems its needing crypto |
20:47.24 | Jordinar | tools for writing to flash, etc. |
20:47.50 | khem | Jordinar: how does it end there is a question I would have expected it to be under some sort of target or cross or native build trees |
20:48.15 | cazze | khem: so bitbake crypto will do the job? |
20:48.18 | khem | Jordinar: are they cross tools |
20:48.25 | khem | cazze: no |
20:48.36 | khem | cazze: its expecting it be on your host |
20:48.44 | khem | its openssl-native not openssl |
20:48.56 | Jordinar | khem: they definitely end there using 'bitbake minimal-image' ... without changing the scripts etc.... only local.conf is modified. |
20:49.32 | cazze | khem: i will thest, thx already for the help |
20:49.36 | cazze | *test |
20:49.44 | Jordinar | khem: no, the binaries there run fine on the buildhost (x86) |
20:50.39 | Jordinar | could be an error in the mtd-utils*.bb ? |
20:50.46 | khem | Jordinar: hmmm I see. so those are for host but why are they being linked into target packages I wonder |
20:50.55 | khem | Jordinar: its possible |
20:51.08 | khem | see what link paths its searching stuff in |
21:04.58 | *** join/#oe ibot (~ibot@rikers.org) |
21:04.58 | *** 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 |
21:07.06 | *** join/#oe toi (~toi@d54C2AA76.access.telenet.be) |
21:08.01 | *** join/#oe zecke (~ich@91-65-96-130-dynip.superkabel.de) |
21:09.18 | cazze | khem: even if i do bitbake openssl it takes openssl-native. how can i change that? |
21:09.24 | *** part/#oe angelox_123 (~Angelo@201-43-66-8.dsl.telesp.net.br) |
21:09.55 | *** join/#oe lisppaste (~lisppaste@common-lisp.net) |
21:13.10 | Crofton | khem, do you mind if I push the patch I posted on the list yesterday? |
21:13.29 | Crofton | and I will have a smal updat eto the gnuradio native sdk that needs to go |
21:16.33 | *** join/#oe chouimat (~mathieu@kde/developer/chouinard) |
21:18.53 | Crofton | if I REDEPEND on pkgconfig-dev, do I need to DEPEND on pkgconfig? |
21:20.22 | khem | Crofton: sure go ahead |
21:20.30 | Crofton | k |
21:20.31 | kergoth_ | only if you need pkgconfig to build. if you only require it to run, you don't need it in DEPENDS, it'll know to build it |
21:20.44 | khem | Crofton: actually, I am waiting for pb_ email on todays TSC meeting minutes |
21:20.49 | *** part/#oe henry1 (~honzhan2@nat/cisco/x-jifqfaufiwooytjp) |
21:20.55 | khem | then we might be able to cut a release branch soon |
21:21.06 | Crofton | I posted the one, both should not have broad impact |
21:21.26 | khem | Jordinar: I will see if I can get around to reproducing it |
21:21.48 | khem | Jordinar: but problem is basically the same what Iexplained somehow linker is searching wrong libs/objects |
21:22.32 | Jordinar | khem: yeah, I agree .... but I really don't know where to tamper in the oe files to fix that |
21:22.34 | khem | cazze: well you can use ASSUME_PROVIDED = "openssl-native" that way it will use the native version from your build host so make sure you have it there |
21:22.46 | khem | Jordinar: ok np |
21:22.59 | Jordinar | I guess that nothing should write its stuff to build/minimal ..... that's what it does here |
21:23.00 | khem | Jordinar: you can summarize the issue on mailing list |
21:23.11 | khem | that will serve as reference for offline work |
21:23.30 | khem | I dont know if I can but if I do come around with some time I will try to fix it |
21:23.56 | Jordinar | didn't work much with lists ..... just writing an email with the info to ..... ? |
21:24.20 | khem | look at openembedded.org |
21:24.45 | Jordinar | ic. |
21:26.01 | *** join/#oe timtimred (~meh@85.210.140.138) |
21:26.41 | *** join/#oe hansdampf (~moritz@212.77.182.8) |
21:31.59 | *** part/#oe little_owl (~little_ow@5e011ddc.bb.sky.com) |
21:32.20 | khem | kergoth_: I have a patch but I have do_patch overridden |
21:32.43 | khem | kergoth_: so I want to copy this patch into workdir but as a normal file and then apply myself |
21:32.56 | kergoth_ | ;apply=no |
21:33.00 | khem | kergoth_: apply=no and what other attribute |
21:33.02 | khem | ok |
21:33.07 | kergoth_ | hmm |
21:33.14 | kergoth_ | it *should* unpack a patch that's set to apply=no |
21:33.17 | kergoth_ | but verify that :) |
21:33.31 | khem | another problem is that I have patches/ folder being overwritten so its better to keep it on topdir |
21:33.54 | khem | hmmm I think I have hijacked unpack too |
21:34.06 | khem | so basically I have to manually symlink it |
21:36.58 | *** join/#oe redguy (~matik@unaffiliated/redguy) |
21:37.18 | kergoth_ | heh |
21:39.48 | *** join/#oe angelox_123 (~Angelo@201-43-66-8.dsl.telesp.net.br) |
21:43.30 | CIA-71 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * rc149a3e6f7 10openembedded.git/recipes/tasks/task-mythtv.bb: |
21:43.30 | CIA-71 | task-mythtv: new task to aggregate mythtv related packages |
21:43.30 | CIA-71 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
21:43.32 | CIA-71 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r1ff4b0a7bf 10openembedded.git/recipes/mythtv/mythplugins_0.23+fixes.bb: |
21:43.32 | CIA-71 | mythplugins_0.23+fixes.bb: improved installation, commented out apache stuff |
21:43.32 | CIA-71 | commented out apache stuff; apache has too many issues building |
21:43.32 | CIA-71 | use lighttpd! |
21:43.32 | CIA-71 | improved the postinst, make sure the needed modules are enabled |
21:43.32 | CIA-71 | in the web server configuration file |
21:43.33 | CIA-71 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
21:43.33 | CIA-71 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r537f94646e 10openembedded.git/recipes/images/james-image.bb: |
21:43.34 | CIA-71 | james-image: image for the james, a home entertainment solution |
21:43.34 | CIA-71 | see http://www.elinux.org/BeagleBoard/James for outdated doc |
21:43.35 | CIA-71 | will be updated (and maybe relocated) in the future |
21:43.46 | CIA-71 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
21:43.47 | CIA-71 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r669a9b9c0a 10openembedded.git/recipes/tasks/task-internetserver.bb: |
21:43.49 | CIA-71 | task-internetserver: task to aggregate internet server functionality |
21:43.50 | CIA-71 | apache/php/mysql/perl/ftp |
21:43.50 | CIA-71 | other servers might be added in due time |
21:43.50 | CIA-71 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
21:43.50 | CIA-71 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r12d3b6eaf3 10openembedded.git/recipes/gtkmm/ (5 files): |
21:43.50 | CIA-71 | gtkmm: added gtkmm-demo package |
21:43.51 | CIA-71 | There were some unpacked files in /usr/share/gtkmm-2.4/demo/ |
21:43.51 | CIA-71 | This patch addes a new package gtkmm-demo and stuffs the files from |
21:43.52 | CIA-71 | that demo dir in it |
21:43.52 | CIA-71 | Also added INC_PR |
21:43.53 | CIA-71 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
21:45.06 | CIA-71 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * rde524aeeec 10openembedded.git/MAINTAINERS: |
21:45.07 | CIA-71 | MAINTAINERS: added james-image + tasks to my entry |
21:45.07 | CIA-71 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
21:51.02 | Tartarus | Hmm |
21:51.12 | Tartarus | Is there a SlugOS combo that's supposed to build atm? |
21:56.30 | *** join/#oe angelox_123 (~Angelo@201-43-66-8.dsl.telesp.net.br) |
21:57.33 | *** join/#oe redguy (~matik@unaffiliated/redguy) |
22:00.29 | eFfeM | Tartarus: the testing page has some |
22:00.41 | eFfeM | nslu2le/be slugos slugimage iirc |
22:00.49 | Tartarus | ah right |
22:00.50 | eFfeM | calling it a day, cya all tomorrow & have fun! |
22:00.53 | Tartarus | later |
22:02.06 | *** join/#oe pb__ (~pb@blundell.swaffham-prior.co.uk) |
22:04.50 | *** join/#oe redguy (~matik@chello089076237104.chello.pl) |
22:04.50 | *** join/#oe redguy (~matik@unaffiliated/redguy) |
22:12.11 | blindvt | khem, please: sed -i -e 's/diretory/directory/g' conf/local.conf.sample && git commit -s -m 'local.conf.sample: commentary typo fixc' && git push -v --thin |
22:12.16 | blindvt | khem, TIA |
22:12.43 | blindvt | drats |
22:12.50 | blindvt | khem, please: sed -i -e 's/diretory/directory/g' conf/local.conf.sample && git commit -s -m 'local.conf.sample: commentary typo fix' && git push -v --thin |
22:13.12 | blindvt | (fixes typo in commit message of commentary typo fix of sample conf ;) |
22:13.22 | Jay7 | https://spreadsheets.google.com/ccc?key=0AhY8lmfkCabTdFlPQ1ozR2ZNM0Z4ckpLZ3VOLVE2dnc&authkey=CKy8lbkH#gid=0 |
22:13.27 | Jay7 | vmstat graph |
22:13.39 | Jay7 | ka6sox-work: ^^ |
22:14.55 | *** join/#oe NTU (~ntu@unaffiliated/neo-the-user) |
22:16.19 | khem | blindvt: thx will do |
22:16.28 | *** join/#oe redguy (~matik@unaffiliated/redguy) |
22:17.05 | blindvt | khem, i'm starting from a pristine clone now. Let's see how far i get.. |
22:17.28 | *** join/#oe martinambrose (~martinamb@c-98-198-169-228.hsd1.tx.comcast.net) |
22:18.36 | khem | blindvt: fantastic. |
22:18.44 | khem | blindvt: how is life ? |
22:19.02 | khem | blindvt: geared enugh for a uclibc release yet? |
22:19.18 | *** join/#oe redguy (~matik@unaffiliated/redguy) |
22:19.20 | blindvt | khem, pfff. This one was a pretty bad year in RL for me |
22:19.56 | khem | blindvt: I understand |
22:21.34 | *** join/#oe redguy (~matik@chello089076237104.chello.pl) |
22:21.34 | *** join/#oe redguy (~matik@unaffiliated/redguy) |
22:22.05 | blindvt | khem, as to a release: a 1.0 would only warrant a full SUSv4 audit and while i've started to add an automated API checker to the testsuite, i have a much improved version of that checker lying around here. Note, however, that i didn't really start to _check_ nor improve our POV wrt SUSv4, so a 1.0 is not really realistic soonish. We could talk about the 0.9.32 though (or any backports that would warrant a 0.9.31.x) |
22:23.04 | Tartarus | <PROTECTED> |
22:23.13 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
22:23.16 | Tartarus | Isn't gobject-introspection stuff supposed to be disabled? |
22:23.30 | kergoth_ | SUSv4? hmm |
22:28.49 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
22:28.57 | *** join/#oe redguy (~matik@unaffiliated/redguy) |
22:30.33 | khem | blindvt: ok .32 is fine too |
22:30.41 | khem | blindvt: I want nptl out of door |
22:31.02 | khem | and it will be first version with nptl so .32 is fine as it crystalizes |
22:31.11 | khem | we can have 1.0 release |
22:31.48 | blindvt | khem, thing is that we (as in NPTL) currently break horrible with gcc trunk since somebody had the bright idea to DCE some of our strong aliases |
22:32.30 | blindvt | khem, 4.6 is not yet released but we will have to sort that out rather soon, given the schedule of 4.6.0 |
22:34.08 | *** join/#oe pespin (~pespin@90.163.50.117) |
22:34.11 | blindvt | khem, there are a couple of minor outstanding hunks that beg for consideration, like the ldd tracer strip patchlet that was sent to the ML and maybe a few other bits that i don't remember offhand |
22:40.43 | blindvt | ok. i'll send the ext4 image stuff tomorrow. |
22:40.52 | blindvt | g'night, all! |
22:44.26 | CIA-71 | 03Yuri Bushmelev <jay4mail@gmail.com> 07master * r1a9d655a29 10openembedded.git/recipes/ (ltrace/ltrace_0.5.3.bb tasks/task-cli-tools.bb): ltrace: exclude from build for SH3/SH4 targets |
22:46.09 | Jay7 | hm.. |
22:53.29 | *** join/#oe GNUtoo|laptop (~gnutoo@95.232.144.102) |
22:53.40 | khem | blindvt: 4.6.0 should happen next year |
22:53.49 | khem | blindvt: we worry about it then |
22:54.50 | khem | blindvt: honestly uclibc has been neglected on my part for past few months |
22:55.36 | Jay7 | should I check Archived checkbox in patchwork? |
22:55.39 | Jay7 | what this mean? |
22:57.54 | *** join/#oe ant__ (~andrea@host252-254-dynamic.31-79-r.retail.telecomitalia.it) |
22:59.55 | khem | Jay7: yes its stored |
23:00.18 | ant__ | hey khem |
23:01.22 | Jay7 | applied then |
23:01.31 | *** part/#oe angelox_123 (~Angelo@201-43-66-8.dsl.telesp.net.br) |
23:02.27 | khem | ant__: hi |
23:03.10 | ant__ | angstrom-eglibc for armv5te has just built fine |
23:03.27 | ant__ | we should really move to eglibc per default |
23:03.51 | ant__ | I'll compare the sizes |
23:03.56 | CIA-71 | 03Khem Raj <raj.khem@gmail.com> 07master * reb6a1aa091 10openembedded.git/recipes/linux/ (3 files in 2 dirs): |
23:03.56 | CIA-71 | linux-efikamx: Fix the existing 2.6.31 recipe to use lower case letter in package name |
23:03.56 | CIA-71 | * Use upstream Amit's branch for git recipe |
23:03.56 | CIA-71 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
23:04.02 | Tartarus | curses, quite loudly, scripts that do @python@, @perl@ and so forth |
23:04.04 | khem | ant__: angstrom-2010 uses eglibc by default already |
23:04.08 | CIA-71 | 03Khem Raj <raj.khem@gmail.com> 07master * ra6e303aed1 10openembedded.git/recipes/eglibc/ (eglibc_2.11.bb eglibc_2.12.bb eglibc_svn.bb): |
23:04.09 | CIA-71 | eglibc_2.11/eglibc_2.12/eglibc_svn: Upgrade to latest SVN tip |
23:04.09 | CIA-71 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
23:04.11 | CIA-71 | 03Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> 07master * rd53f2eaae3 10openembedded.git/conf/local.conf.sample: |
23:04.11 | CIA-71 | local.conf.sample: commentary typo fix |
23:04.11 | CIA-71 | Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> |
23:04.11 | CIA-71 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
23:04.12 | CIA-71 | 03Khem Raj <raj.khem@gmail.com> 07master * rf5c7beb6f5 10openembedded.git/conf/distro/minimal.conf: |
23:04.12 | CIA-71 | minimal.conf: Pin QT version to 4.7.0 |
23:04.12 | CIA-71 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
23:04.14 | CIA-71 | 03Tim Harvey <harvey.tim@gmail.com> 07master * r2c2013c90f 10openembedded.git/recipes/nuttcp/ (nuttcp/nuttcpd.init nuttcp_7.1.3.bb): |
23:04.14 | CIA-71 | nuttcp: new recipe |
23:04.14 | CIA-71 | Signed-off-by: Tim Harvey <harvey.tim@gmail.com> |
23:04.14 | CIA-71 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
23:04.16 | CIA-71 | 03Graham Gower <graham.gower@gmail.com> 07master * rec8e3903c1 10openembedded.git/conf/distro/include/sane-toolchain.inc: |
23:04.16 | CIA-71 | sane-toolchain.inc: remove duplicate line. |
23:04.16 | CIA-71 | Signed-off-by: Graham Gower <graham.gower@gmail.com> |
23:04.16 | ant__ | he..I'm working on 'stable' ;) |
23:04.23 | Tartarus | khem: Are you sure gcc 4.4.4 + powerpc breaks? |
23:04.28 | khem | Tartarus: yes |
23:04.29 | Tartarus | I didn't get that same fatal error |
23:04.36 | Tartarus | At least no quite so quick, but k |
23:04.41 | Tartarus | Want me to re-sub? |
23:04.43 | khem | Tartarus: err |
23:04.45 | Tartarus | Or just update |
23:05.03 | khem | Tartarus: update add my sign-off and push |
23:05.25 | khem | Tartarus: better you push today tomorrow we will have another test branch |
23:05.34 | Tartarus | yeah |
23:05.43 | khem | Jay7: now efikamx kernel should build fine |
23:05.49 | khem | Jay7: try that out |
23:05.57 | Tartarus | Need to, ahem, bitchslap gobject-introspection real quick too |
23:06.27 | ant__ | khem: still I'm tempted by uclibc..how is the NPTL status? |
23:06.37 | khem | two more bike rides to work and then I have 20 dollars gift card |
23:06.42 | ant__ | have you unified the recipes? |
23:06.54 | Jay7 | khem: thanks, I'll restart efika builds this night |
23:06.57 | khem | ant__: it is or was good last time I did stuff |
23:07.32 | khem | ant__: arm/ppc/mips/sh/x86/x86_64 support nptl and seem to work to some extent |
23:07.38 | ant__ | iirc uclibc-git was needed for nptl |
23:07.59 | khem | ant__: yes the reason for that is because there is no uclibc release yet with nptl |
23:08.10 | ant__ | oh, I see... |
23:08.11 | khem | soon we may have .32 |
23:08.21 | khem | then that will be first official nptl release |
23:09.38 | *** join/#oe dth_ntb (~dth@a89-183-11-169.net-htp.de) |
23:12.01 | CIA-71 | 03Camille Moncelier <moncelier@devlife.org> 07master * rcf67dc1bb1 10openembedded.git/recipes/dropbear/ (dropbear.inc dropbear/default): |
23:12.01 | CIA-71 | dropbear: Removed openmoko references. Added /etc/default/dropbear |
23:12.01 | CIA-71 | Signed-off-by: Camille Moncelier <moncelier@devlife.org> |
23:12.01 | CIA-71 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
23:14.35 | *** join/#oe guufy (~Guufy@70-35-57-218.static.wiline.com) |
23:15.25 | CIA-71 | 03Maksym Parkachov <lazy.gopher@gmail.com> 07master * r04531031ee 10openembedded.git/recipes/mcpp/ (mcpp.inc mcpp_2.7.2.bb): |
23:15.26 | CIA-71 | mcpp: added new recipe for version 2.7.2 |
23:15.26 | CIA-71 | * created .inc file for both target and native version |
23:15.26 | CIA-71 | * added version 2.7.2 |
23:15.26 | CIA-71 | Signed-off-by: Maksym Parkachov <lazy.gopher@gmail.com> |
23:15.26 | CIA-71 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
23:16.44 | obi | khem: can you please take a look at my patch to pkgconfig.bbclass and ack or nak it? http://patchwork.openembedded.org/patch/3427/ |
23:17.36 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
23:17.36 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
23:17.47 | obi | it's a build fix, but not many people seem to care |
23:17.54 | khem | obi: patch looks sane to me |
23:18.17 | khem | let me pull it into my tree where I will launch a clean build now |
23:18.21 | Tartarus | The .pc one? |
23:18.25 | obi | thanks |
23:18.26 | Tartarus | What is broken today? |
23:18.28 | khem | obi: do u have patches pending on this patch |
23:18.29 | obi | Tartarus: yes |
23:18.46 | CIA-71 | 03Tom Rini <tom_rini@mentor.com> 07org.openembedded.dev * r4e5f9e1010 10openembedded.git/conf/distro/include/ (sane-toolchain-eglibc.inc sane-toolchain-glibc.inc): |
23:18.46 | CIA-71 | sane-toolchain-*glibc.inc: Use -O2 on PowerPC |
23:18.46 | CIA-71 | In FULL_OPTIMIZATION use -O2 on powerpc due to some problems |
23:18.46 | CIA-71 | with libgcc.a and -Os when using gcc 4.5.x. |
23:18.46 | CIA-71 | Signed-off-by: Tom Rini <tom_rini@mentor.com> |
23:18.46 | CIA-71 | Acked-by: Khem Raj <raj.khem@gmail.com> |
23:19.08 | obi | khem: no, but i will create a new overlay which depends on this patch |
23:19.25 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |
23:19.33 | Tartarus | khem: Bah |
23:19.38 | Tartarus | didn't update commit msg, did update comment |
23:19.49 | khem | Tartarus: thats ok :) |
23:19.59 | obi | Tartarus: well, it's described in the commit: |
23:20.02 | khem | comment is more important |
23:20.04 | obi | "* .pc files must be installed explicitly to avoid causing |
23:20.04 | obi | <PROTECTED> |
23:20.04 | obi | <PROTECTED> |
23:20.04 | obi | <PROTECTED> |
23:20.26 | Tartarus | obi: That makes more sense with your overlay msg above |
23:20.28 | obi | today, pkgconfig.bbclass does a recursive search for *.pc and installs every file it can find |
23:20.28 | Tartarus | Which isn't :) |
23:22.02 | obi | actually, it depends on the packages you want to use |
23:22.22 | Jay7 | hehe.. opie-notes fails to build by gcc-4.5 |
23:22.31 | Jay7 | as I understand at least |
23:22.55 | Jay7 | it builds ok for angstrom but fails for minimal |
23:23.02 | khem | Jay7: lot of opie recipes dont build with gcc 4.5 |
23:23.24 | khem | there was a new release coming I guess which is more modern C++ |
23:23.28 | obi | Tartarus: there are many .pc files, which don't get installed, due to configure not finding some library or another. if another configure script then checks for that package, it will fail to build or link |
23:23.30 | khem | chances of that working is better |
23:23.45 | Jay7 | so, opie-image cant be built for minimal distro |
23:23.55 | khem | I think using standard install for .pc files is sufficient |
23:24.30 | Jay7 | is thinking how to describe this better on testing page.. |
23:25.02 | Tartarus | well, angstrom isn't gcc 4.5 is it? :) |
23:26.53 | khem | Tartarus: angstrom-2010 is |
23:27.33 | khem | but i think angstrom is more and more geared to ARM these days |
23:28.55 | khem | Jay7: whats the error |
23:29.04 | Jay7 | http://tinderbox.openembedded.net/public/logs/task/10238054.txt |
23:29.21 | *** join/#oe Martin_B (~martin@pool-21-67-198-89.dbd-ipconnect.net) |
23:29.32 | Jay7 | khem: angstrom have similar messages but as warnings and for other files |
23:30.24 | Jay7 | an, ant__ pointed me to warnings for mainwindow.cpp too |
23:31.08 | ant__ | yep, only warningswith old gcc |
23:31.37 | Jay7 | btw, other problem of oestats - you can't return from log view to build view |
23:32.07 | Jay7 | I should collect this somewhere in preparation for oestats-next :) |
23:32.45 | ant__ | khem: http://pastebin.ca/1995077 |
23:33.25 | ant__ | he..O2 vs. Os too |
23:33.48 | ant__ | we need runtime testers :p |
23:34.30 | khem | Jay7: yeah I have seen that error. Its a warning from newer compilers |
23:34.45 | khem | Jay7: I have fixed few things in OE to shush this warning |
23:34.52 | khem | but was not interested in opie |
23:36.05 | khem | ant__: that code needs to be fixed |
23:36.45 | ant__ | yes, starts to bitrot |
23:39.03 | Crofton | opie does not have any momentum |
23:39.54 | Crofton | angstrom is "geared" to what people ask for and work on |
23:40.14 | CIA-71 | 03Tom Rini <tom_rini@mentor.com> 07org.openembedded.dev * r8d906dfca2 10openembedded.git/recipes/gobject-introspection/ (2 files in 2 dirs): |
23:40.14 | CIA-71 | gobject-introspection: Use /usr/bin/env for python |
23:40.14 | CIA-71 | Scripts that do #!@PERL@ or #!@PYTHON@ and replace that with |
23:40.14 | CIA-71 | a full path are in danger of breaking in certain environments |
23:40.14 | CIA-71 | (such as some autobuilders) and should instead use /usr/bin/env. |
23:40.15 | CIA-71 | While in here, use GNOME_MIRROR for the sources. |
23:40.16 | CIA-71 | Signed-off-by: Tom Rini <tom_rini@mentor.com> |
23:42.52 | Jay7 | well.. |
23:43.01 | Jay7 | have updated Testing page.. |
23:43.04 | ant__ | Crofton: Opie happens to produce small working images, though severely outdated |
23:43.19 | ant__ | it attracts more users to #oe |
23:43.23 | ant__ | ;) |
23:43.27 | Jay7 | * usable images :) |
23:43.49 | Crofton | sure |
23:44.14 | Crofton | but is outdated |
23:44.20 | Crofton | and hard to keep up in dev |
23:44.32 | ant__ | well, yes and not |
23:44.40 | ant__ | bluelightning is doing miracles |
23:44.47 | Jay7 | very useful to use on outdated hardware :) |
23:45.31 | ant__ | still, two core recipes with legacy staging need love... |
23:46.19 | Jay7 | it would be great to remove legacy staging before release.. |
23:46.24 | Jay7 | but seems too late now |
23:46.44 | ant__ | thought about giving 'sugar' distro to his 3yrs old kid... |
23:46.57 | ant__ | while I thought he stole my iphone |
23:47.00 | ant__ | :/ |
23:47.16 | ant__ | that's about ease of use |
23:47.38 | Jay7 | Testing page source is about ease of use :\ |
23:47.50 | Jay7 | even for me already.. |
23:48.15 | Jay7 | I'm thinking about splitting table by distro |
23:48.28 | Jay7 | or by machines |
23:48.41 | ant__ | he..we come back to the damned matrix |
23:48.50 | Tartarus | google form :) |
23:48.56 | Jay7 | yeah.. |
23:49.01 | Tartarus | And that was essentially the point I was trying to make |
23:49.09 | Tartarus | Did my first builds and report the other week |
23:49.20 | Tartarus | And yeah, I wanted to improve the wiki part |
23:49.23 | Tartarus | since it was kinda painful |
23:49.40 | Jay7 | dokuwiki tables syntax is more elegant... |
23:49.53 | Jay7 | but with such big table it will suxx anyway |
23:50.15 | Tartarus | anything without actually 90% working graphical editing is a pain |
23:50.30 | Tartarus | And then it's just a slightly different pain :) |
23:50.59 | Jay7 | can mediawiki use FCKeditor or TinyMCE? |
23:51.08 | Jay7 | both have tables support iirc |
23:51.22 | Jay7 | my drupal and typo3 installations have it at least |
23:55.57 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
23:57.55 | ant__ | btw, any idea about this recuyrrent notes? |
23:57.57 | ant__ | cp: cannot stat `/oe/build/tmp/work/i686-linux/stagemanager-native-0.0.1-r15/sysroot-destdir//oe/build/tmp/*': No such file or directory |
23:58.24 | ant__ | this is first occurrence |
23:58.25 | Tartarus | it's still vaugely on my list to work out |
23:58.38 | ant__ | long standing issue |
23:58.56 | ant__ | other is the 'inherit gettext' |
23:59.05 | Jay7 | khem: I've started minimal/efikamx/console-image build |
23:59.12 | *** join/#oe xobs (~smc@cm152.psi156.maxonline.com.sg) |
23:59.23 | ant__ | well, Missing inherit gettext? |