IRC log for #oe on 20101117

00:00.08Jay7khem: well, what about our build?
00:00.24reactor16any one use dreambox ?
00:01.03Jay7I have no idea about device_table and locale-base-fr-fr bugs..
00:03.27Jay7tried to clean glibc and rebuild
00:03.30Jay7w/o success
00:03.46Croftonany idea how to use gmail for smtp, but not have your gmail address show up in the email?
00:04.21Jay7ah.. seems it is using eglibc
00:04.47TartarusCrofton, does gmail handle the domain or no?
00:04.53Tartarusif no, I think you can't
00:05.07Croftonok
00:05.26Jay7Crofton: use envelope-from?
00:05.46Croftonisn't working
00:05.54Jay7heh.. seems gmail is too smart
00:06.16Croftonyeah
00:06.17Jay7did you have your address attached to gmail into gmail account settings?
00:06.43Jay7i.e. as address from which you can send mail via web-interface
00:07.11ka6sox-workmorning
00:08.14CroftonJay7, trying that now
00:08.40*** part/#oe robtow (~a0272704@nat/ti/x-bzdssvkvtxurgnve)
00:08.41Jay7as other option register separate account specially for this :)
00:09.03Croftonah
00:09.11CroftonI think this worked, thanks JaMa|Off
00:09.13Jay7btw, gmail can use 'plussed' addresses iirc
00:09.14CroftonJay7,
00:09.35Jay7yourmail+something@gmail.com
00:10.22Jay7I've even heard that it can mark mail arriving to such address with 'something' label
00:10.33Jay7but have not checked this
00:10.55kergoth_its not automatic, you have to create filters for it
00:11.00kergoth_but its doable easily enough
00:11.28*** join/#oe robtow (~a0272704@nat/ti/x-kpfzkddbkuqpphju)
00:12.58Croftonadding the address I am subscribed to the OE list from to my gmail account worked
00:13.21Jay7cool
00:13.40Jay7Crofton: can you write some short instructions on wiki?
00:13.54Jay7about using git-send-email
00:14.39CroftonI copied from the wiki
00:14.46CroftonI suppose I could add some notes
00:14.53Jay7ah.. good :)
00:16.20Jay7wow
00:16.32Jay7khem: build was finished
00:17.10Jay7I've rebuild eglibc w/o GLIBC_GENERATE_LOCALES
00:17.39Jay7but requiring fr_FR locale is wrong imho
00:17.50ant__Jay7: hey
00:17.59Jay7classes/image.bbclass:IMAGE_LINGUAS ?= "de-de fr-fr en-gb"
00:18.00Jay7haha
00:18.07kergoth_that's a really lame default
00:18.13kergoth_also, arbitrary
00:18.19Jay7forgotten imho
00:18.34kergoth_'s had that overridden in his site.conf for so long he probably forgot about it
00:18.39ant__I'm deleting some old tmpdirs..the eglibc was fine *withy* locales generation
00:18.56kergoth_damnit, i broke the bitbake cache somehow.. hrm
00:19.14ant__s@i+...can't get used to this new kb
00:19.20Jay7well.. so, I should note that GLIBC_GENERATE_LOCALES should be consistent with IMAGE_LINGUAS then
00:20.09Jay7btw, lot of images have it overriden
00:20.33Jay7well, ok
00:20.52Jay7khem: build successed anyway
00:21.01Jay7so you can push that changes
00:22.37ant__kergoth_: I noticed some/most images are setting IMAGE_BASENAME..
00:22.44kergoth_they should be, yes
00:22.51ant__well, exporting
00:22.53*** join/#oe kerim (~kerim@188.3.59.15)
00:23.05kergoth_oh, that's silly
00:23.36ant__is it even whitelisted?
00:23.47kergoth_not sure what you mean
00:23.49ant__ah ha..first grep match..
00:23.59ant__./classes/image.bbclass:# "export IMAGE_BASENAME" not supported at this time
00:24.13kergoth_that just means its doing IMAGE_BASENAME[export] = "1"
00:24.20kergoth_due to old bitbake not supporting the export directive without =
00:24.27ant__k
00:24.32kergoth_doesn't explain why its being exported at all :)
00:24.40ant__still it seems to me unnecessary
00:24.43kergoth_yep
00:24.44kergoth_i agree
00:24.44ant__right
00:32.50Jay7seems I should setup git-send-email too..
00:41.27kergoth_grumbles
00:44.49ant__late here...good night
00:51.26*** join/#oe kgilmer (~kgilmer@i114-182-187-151.s06.a014.ap.plala.or.jp)
00:55.53Jay7khem: I've posted patch to ML
00:55.53ka6sox-workkhem, ping?
00:58.14*** part/#oe mrj10 (~mrj10@mjlap.crhc.uiuc.edu)
01:02.29CroftonAny ideas?
01:02.30Croftonhttp://tinderbox.openembedded.org/public/logs/task/10211209.txt
01:02.37Croftontracker dies looking for hal
01:08.14Jay7Crofton: what is in config.log?
01:08.31Croftonnot sure
01:08.43CroftonI am trying to bitbake hal and restarting is my guess
01:12.02Jay7have started testbuilder for minimal distro and goes sleep
01:12.48Croftongn
01:13.35ka6sox-workJay7, are you still using that spreadsheet?
01:14.03Jay7Crofton: btw, have you seen your mail in your gmail.com mailbox?
01:14.19Croftonwhich email?
01:14.32Jay7which was sent by git-send-email
01:14.34Croftonthe confirmation email for the new address goes to that ddress
01:14.53Jay7ka6sox-work: I've not updated it
01:14.54CroftonI thnk it stopped going there
01:15.17Jay7ka6sox-work: have nothing new to show..
01:15.51Croftonok tracker is compiling now
01:15.51Jay7I've sent my patch to ML by git-send-email but I don't see it in inbox
01:16.00Croftonlooks like it need some form of depends on hal
01:16.10Croftonuses a multi core builder
01:17.19ka6sox-workJay7, thanks.
01:17.28ka6sox-workmulti-core only means it fails faster.
01:18.17Jay7:))
01:18.36Jay7ka6sox-work: btw, I'm using 4/2 threads now
01:18.56TartarusJay7: BB/make or make/BB ?
01:19.00Jay7bb/make
01:19.16Tartarustried tuning it up higher?
01:19.25Jay7seems more bb threads will not produce better time..
01:19.26Tartarusis starting to question his rule of thumb there
01:19.31ka6sox-workJay7, kewl! that should help to keep it out of iowait.
01:19.38Jay7HDD bw limit reached
01:19.59Jay7but I should analyze vmstat output..
01:20.16ka6sox-workright..thats why multi-core and the rule of J#= 2X number of Cores FAILS.
01:20.41TartarusI had been doing -j#*1.5, threads=N
01:20.56ka6sox-workabove 2cores and -j 4 seems to hit a wall.
01:21.11Jay7ideal case is bb threads == No of cores and -j2 :)
01:21.33Tartarusit's sure true that very few things can make use of larger -j numbers
01:21.41Tartarusgcc and *glibc and that's about it
01:22.05Jay7I've tought today about distributed building system
01:22.59ka6sox-workJay7, I'm thinking about 2 cores on each of 4 machines with -j4 and icecc
01:23.01Jay7nothing useful..
01:23.28ka6sox-workbut autoconfig and other things will slow that down.
01:23.34Tartarusyeah
01:23.43Jay7ka6sox-work: 4 cores have almost the same price imho
01:23.49TartarusThat's one of the bottlenecks to making icecc a win over single big boxe
01:23.50Tartaruss
01:23.51Jay7+- 20$ :)
01:24.12*** join/#oe fraxinath (~quassel@p4FD651F3.dip.t-dialin.net)
01:24.14ka6sox-workJay7, its mostly about I/O BW...not cores
01:24.21Jay7Phenom II X4 is very cheap now
01:24.37Tartarus'now'? heh, I don't wanna know how cheap they are now
01:24.40Jay7see, I'm using 4/2 :)
01:24.46Tartarusgot one when they were kinda new and would have sworn it was cheap then
01:24.51ka6sox-workreally...its *all* about I/O BW when building
01:25.01Tartarusmodel name      : AMD Phenom(tm) II X4 940 Processor
01:25.05Tartarusis what  i've got local
01:25.27Jay7Tartarus: I've awaited for X6 and got it now :)
01:25.29ka6sox-workI have 2ea 2378's
01:25.37ka6sox-workso 8 cores.
01:25.54Jay7there are 12-cored opterons already..
01:26.54Jay7I should sleep!
01:27.07ka6sox-worknn Jay7
01:27.09ka6sox-worksleep well.
01:36.26Tartaruskhem: 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.07kergothmeh
03:14.08*** join/#oe mfhk (~chatzilla@cm61-15-76-62.hkcable.com.hk)
03:16.16kergothhrm, 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.20kergothtries to track down why
03:17.11khemkergoth: I am bewildered
03:17.18khemthere is this git repo
03:17.27khemif I clone it manually works all ok
03:17.34khembut bitbake fetcher is failing
03:17.41kergothwhat's the failure?
03:18.25khem"git://gitorious.org/efikamx/linux-kernel.git;protocol=git"
03:19.49khemhttp://pastebin.com/4gNUc1Xi
03:20.12kergothweird
03:20.19kergoththat same command works at a commandline?
03:21.50khem<PROTECTED>
03:21.53khemworks
03:22.37kergothweird.
03:22.39kergothhmm
03:22.56khemI have two gits
03:22.59khemand both work
03:23.10khemone is from native staging
03:23.30kergothno idea, that's a strange one
03:23.43khemit happens all the time
03:27.21mfhkI 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.44khemmfhk: well HTC seems to working with oe
03:48.36kergothhacks on bb.cache some more
04:02.13kergothdamnit, with this patch applied: 6816 cached, 387 parsed.  without: 6791 cached, 412 parsed.
04:02.17kergothmutters
04:07.10kergothdoes 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.17eFfeM_workgm
06:58.28eFfeM_workkhem 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.31mckoangood 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.23likewisegm
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.24CIA-7103Chase Maupin <Chase.Maupin@ti.com> 07org.openembedded.dev * r64db5346f3 10openembedded.git/recipes/u-boot/u-boot_git.bb:
09:28.25CIA-71u-boot_git: use SOC_FAMILY for omapl devices
09:28.25CIA-71* Use the SOC_FAMILY override for omapl137 and omapl138 based
09:28.25CIA-71devices.
09:28.25CIA-71Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
09:28.25CIA-71Signed-off-by: Koen Kooi <k-kooi@ti.com>
09:28.26CIA-7103Koen Kooi <k-kooi@ti.com> 07org.openembedded.dev * rabcc9c2948 10openembedded.git/recipes/linux/linux-davinci_git.bb:
09:28.27CIA-71linux-davinci git: update hawkboard
09:28.27CIA-71Signed-off-by: Koen Kooi <k-kooi@ti.com>
09:28.27*** join/#oe playya__ (~playya@unaffiliated/playya)
09:28.28CIA-7103Chase Maupin <Chase.Maupin@ti.com> 07org.openembedded.dev * rb64297415c 10openembedded.git/conf/machine/am180x-evm.conf:
09:28.28CIA-71am180x-evm: Add am180x-evm machine type
09:28.28CIA-71* Add new machine type for the AM180x family of devices. These
09:28.29CIA-71devices are part of the omapl138 SOC_FAMILY.
09:28.29CIA-71Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
09:30.11Jay7hm.. it thought that bb of image for efikamx is hang but seems it was fetching kernel image from git..
09:30.35Jay7well, 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.01eFfeM_workhm, anyone ever got this while building:
10:10.06eFfeM_worksh: /home/frans/workspace/SYHL1_1/C/Linux/openembedded/tmp/staging/x86_64-linux/bin/quilt: /bin/bash: bad interpreter: Text file busy
10:10.24eFfeM_workthis is ubuntu 10.04, /bin/bash exists
10:10.43eFfeM_workis puzzled but thinks kicking the build again might allow it to proceed
10:10.56ka6sox-workeFfeM_work, yes, and I don't remember what fixed it...too late here.
10:11.19eFfeM_worki'll see if it is repeatable
10:11.43eFfeM_workapparently not; a new build does not give the error
10:12.37eFfeM_workkhem, 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.15ericbengood morning
10:17.25ant_workeFfeM_work: there are still some race issues, it seems
10:17.57eFfeM_workguess so, but text file busy is probably an OS or bash issue
10:18.01eFfeM_workhi ericben
10:18.07ant_workat least I solved a repeatable one: lzma-native
10:18.19eFfeM_workah, cool
10:18.26ant_workimagine removing an unneeded dependency cured the thing...
10:18.30ant_workstrange
10:18.33eFfeM_workalso would like to understand the preferred provider thing, see my reply on your mail
10:18.39ant_workyep
10:18.56ant_workand documentation about PREFERRED_VERSION_pn
10:19.08ericbenwhen adding PACKAGE_ARCH = ${MACHINE}, should'nt the workdir be tmp/work/${MACHINE}-angstrom-linux-gnueabi ?
10:20.21eFfeM_workericben: probably (depends on the triplet, and ofc only if you are building for angstrom)
10:20.42ant_workeFfeM_work: see Re: [oe] [PATCH (v2)] Reverse the order of OVERRIDES
10:20.44eFfeM_workI also have this: ppce500v2-oe-linux-gnuspe
10:20.48ant_workoutstanding issue imho
10:21.20eFfeM_workant_work: that's why I added the _local
10:22.08eFfeM_workactually 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.16eFfeM_workwould love to see the _target override though
10:22.29ericbenI 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.03ericbenso meta-toolchain-qte search for qt4-embedded in the machine dirs when it's built in the arch dir
10:23.31ericbendo you have an idea of where I should search for this problem ?
10:26.32eFfeM_workstrange
10:26.47ericbenyes I agree with you :-D
10:26.52eFfeM_worknot really an idea, not something I have too much knowledge about
10:27.13ericbenthis was working fine before, so I'm searching for the comit which broke this
10:32.12eFfeM_workis the problem repeatable ? (have you tried to rm tmp and does it resurface) ?
10:32.35eFfeM_worki expect this to be something in the class stuff
10:32.54ericbenin fact I found this when doing a clean build from scratch
10:33.39ericbenI have overlay + amend.inc + FILESPATHBASE change to pick files from overlays
10:34.40ericbenI'm goiing to try some testing tags to find when that broke
10:44.07eFfeM_workseems 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.12blindvt`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.28blindvt`(osc has this wrong -- since it's using just 2 'p' ;)
11:01.28*** join/#oe playya__ (~playya@unaffiliated/playya)
11:02.44ericbeneFfeM_work: that seems to be a problem in amend.inc. setting PACKAGE_ARCH = "${MACHINE}" in oe's recipe works fine
11:05.25blindvt`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.42ynezzdoes it happen only to me? http://pastebin.com/6RE7417z
11:08.55ericbenynezz: this happens also to me ... when I have a mistake somewhere in a recipe
11:09.14ericbenthe hardest thing is to find where is the mistake as bitbake doesn't provide any log for this
11:09.14ynezzbut it's testing-next from 12th November and bitbake master
11:09.17*** join/#oe ldnunes (~ldnunes@189.114.111.55)
11:09.36ynezzthat's why I'm asking :)
11:09.38ericbenynezz: 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.39RadiooHello, 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.12bandwidthcrunchI 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.41ynezzhm, the parsing error is in openssl recipe and fails also with bitbake 1.10.1
11:48.52ynezzbut I can't clearly see why
11:49.27ynezzhttp://pastebin.com/55kJwULL
11:49.57ynezzParsingErrorsFound 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.52ericbeneFfeM_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.57ericbene
12:08.48ericbeneFfeM_work: setting PACKAGE_ARCH *and* MULTIMACH_ARCH to ${MACHINE}  in amend.inc seems to do the trick
12:10.33CIA-7103Martin Jansa <Martin.Jansa@gmail.com> 07master * r9be2cf18ce 10openembedded.git/recipes/ (5 files in 3 dirs): (log message trimmed)
12:10.33CIA-71jlime,dzen2,puzzles: use RDEPENDS_${PN}
12:10.33CIA-71* it was fixed in whole tree about half year ago
12:10.33CIA-71http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-June/020384.html
12:10.33CIA-71http://comments.gmane.org/gmane.comp.handhelds.openembedded/33440
12:10.33CIA-71* then again about month ago
12:10.34CIA-71http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg11356.html
12:10.53JaMasomeone building micro+eglibc?
12:11.20JaMafor 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.51eFfeM_workericben: ah ok, good find, guess we should document it somewhere
12:35.55eFfeM_workynezz: try running bitbake -v -v -v -D -D -D recipename
12:37.15*** join/#oe yonathanaw (~quassel@122.166.104.245)
12:39.32ericbeneFfeM_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.18eFfeM_workJaMa: 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.23JaMaeFfeM_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.23eFfeM_workyeah, 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.49JaMaeFfeM_work: btw did you notice that your libx11 change is already applied upstream?
13:14.00JaMaso next libx11-1.4 snapshot will have it
13:14.10eFfeM_workcool, will get to it later
13:14.14eFfeM_worknow busy
13:14.28JaMaok :)
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.26obiwhat'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.44JaMaobi: RREPLACES_old = new
13:28.08obii think this will only work if the old package should be removed
13:28.25obibut i already have both packages installed and want to keep both packages after the upgrade
13:28.48JaMathat's RCONFLICTS_
13:29.13pb_JaMa: the other way around, surely.  "RREPLACES_new = old".
13:29.13JaMabut better to test first I'm not 100% sure
13:29.24pb_seems a bit unreasonable to expect the old packages to predict which new ones will be invented to replace them :-}
13:29.30JaMapb_: ah right
13:31.52obiJaMa: 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.16JaMaobi: but that's if you need to remove whole old package before installing new one
13:34.52JaMaRREPLACES can be used if new package only partially replaces old one (that's our case isn't it?)
13:35.26JaMaand I'm not sure that RCONFLICTS are automatically resolved during opkg upgrade
13:35.37JaMauser maybe have to remove it manually first
13:35.51obiah, yes, i see. my guess was that RREPLACES indicates a replacement for an obsolete package
13:38.18obibut 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.33pb_obi: do you actually need to specify a version?
13:39.37JaMaI don't think you have to wrote version there
13:41.08obii think so, because i want to upgrade the old package instead of removing it
13:41.12obithe documentation says:
13:41.18obiRREPLACES
13:41.18obi<PROTECTED>
13:41.38pb_I think that documentation is wrong.
13:42.36obiok
13:42.44*** join/#oe GNUtoo (~GNUtoo@95.232.144.102)
13:42.55*** join/#oe mnabil (~mnabil@41.234.70.134)
13:43.49obii think i should specify a version, because the new package should not replace the upgraded old package ;)
13:44.20obibut in the specific case i'm probably able to bump the version of the old package, making the PR irrelevant
13:44.35eFfeM_workJaMa: wrt the x11 patch,did they apply it just as we gave it? seem to recall there was a change proposal
13:45.05eFfeM_workbut in any case: can we create a similar patch for the current version and apply that one ?
13:45.07JaMaeFfeM_work: no changed
13:45.15eFfeM_workah so we can just push
13:45.20JaMaand then changed host<->target var
13:45.44JaMaeFfeM_work: I meant: no, changed :)
13:45.51eFfeM_workah ok
13:45.57eFfeM_workyeah that was discussed
13:46.10JaMahttp://cgit.freedesktop.org/xorg/lib/libX11/log/
13:46.51foersterfml.  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.52eFfeM_workcan you add that patch to the current libx121 ?
13:46.59eFfeM_workJaMa: ^
13:47.10eFfeM_workbeen involved in other problems over my ears atm
13:47.58JaMatoo and leaving in few minutes, sorry
13:48.04JaMaalso no nios to test it :)
13:48.06eFfeM_workah ok, np
13:51.06Tartarusforester, does it just not test for it being supported?
13:51.10TartarusThat's just another site variable
13:51.11*** join/#oe mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net)
13:52.36foersterTartarus: 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.00foersterI tried setting a site variable, but they do unset ac_cv_* before running tests.
13:53.54TartarusOK, wow, that sounds pretty broken
13:54.07TartarusI'd go and patch the configure scripts too
13:54.15Crofton|roadTartarus: early for you?
13:54.17eFfeM_work<PROTECTED>
13:54.57TartarusCrofton|road, not since my son decided 0600-0630 is his getting up time
13:55.19Tartarusand he's still too young to read a clock :(
13:55.42florianTartarus: This problem sounds familiar :-)
13:55.48Crofton|roadis cursing noisy hotles
13:55.52Crofton|roadhotels
13:59.32eFfeM_workJaMa: patch created, retested that it patches ok for all versions, don't have  a nios tree handy to build it
13:59.38eFfeM_workif ok, please ack and I'll push it
13:59.48eFfeM_workpatch is already send to ML
14:00.37*** join/#oe dth_ntb (~dth@212.23.103.14)
14:07.37pb_RP: are we due to have a TSC meeting today?
14:07.45pb_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.23sakoman_gm
14:24.49sakoman_it seems commit b35109935bdb9e18671456a8c2e404a0c5556c0e breaks all images that include task-native-sdk
14:26.00sakoman_was it intentional to change the name of the package generated?
14:26.22Tartaruskergoth?
14:47.56mckoana Debian based Host PC is no longer valid choice to build OE ?
14:48.30JaMadue git without curl?
14:48.32ericbenmckoan: works fine here
14:48.45mckoanJaMa: yes
14:48.50JaMajust remove ASSUME_PROVIDED git-native from your config I guess
14:49.44JaMaand then build git-native first with -b (because otherwise it will fail to build due to git)
14:50.13mckoanJaMa: and in this case bitbake create git and use it instead of the host provided?
14:50.46JaMay
14:54.52mckoanfunny http://tinderbox.openembedded.net/packages/985559/
14:54.54kergoth_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.00kergoth_sakoman_: what's the behavior?
14:55.21*** join/#oe GNUtoo|laptop (~gnutoo@95.232.144.102)
14:56.18sakoman_kergoth_: the commit removes: RPROVIDES_${PN} = "task-native-sdk"
14:56.40sakoman_so any image that includes task-native-sdk fails due to no provider
14:57.24kergoth_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.42kergoth_shrugs, can easily add it back
14:57.56mckoanericben: works on you ride with Lenny 64bit?
14:58.02kergoth_nothing in the current oe tree seems to behave the way you describe, as far as i can see
14:58.11mckoanericben: s/ride/side
14:58.44sakoman_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.44kergoth_oh, i'm blind
14:58.46kergoth_nods
14:58.56kergoth_why the hell are we doing that, again?
14:59.12kergoth_mutters
14:59.17sakoman_I have no freakin' clue -- I've always found it bizzare and confusing
14:59.25sakoman_but I just lived with it
15:00.03kergoth_well, i'll bring back the rprovides for now
15:00.07kergoth_we can fix the thing after the release
15:00.20kergoth_well, the rprovides is probably good either way
15:00.24kergoth_but the recipes should get a rename :)
15:00.30sakoman_yup, I agree
15:00.55sakoman_the -native at the end is confusing at best, and liekly wrong since it isn't a native package
15:01.08kergoth_clearly you aren't the only one confused by this, since i got screwed up by it too :)
15:01.29sakoman_I've had a gazillion gumstix customers ask me about it too
15:01.39sakoman_it is definitely a faq
15:02.56kergoth_k, fixed, thanks for spotting it
15:03.43ericbenmckoan: I'm on a debian sid 64bits
15:03.53CIA-7103Chris Larson <chris_larson@mentor.com> 07master * rc4912d6abf 10openembedded.git/recipes/tasks/task-sdk-native.inc:
15:03.54CIA-71task-sdk-native: resurrect RPROVIDES_${PN}
15:03.54CIA-71Signed-off-by: Chris Larson <chris_larson@mentor.com>
15:04.06mckoanericben: I suppose that sid has a newer git :-(
15:04.17ericbenmckoan: Version: 1:1.7.2.3-2
15:04.26CIA-7103Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07master * ra2820f8fd2 10openembedded.git/recipes/xorg-lib/ (8 files in 5 dirs): (log message trimmed)
15:04.26CIA-71libX11: patch configure.ac so a nios2 system is not seen as an os2 system.
15:04.26CIA-71The 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.26CIA-71This is already accepted upstream and will be in 1.4
15:04.27CIA-71http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=affc2488a7f2660a74dc8354fc3e0bff2c4f879c
15:04.27CIA-71Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
15:04.28CIA-71Acked-by: Martin Jansa <Martin.Jansa@gmail.com>
15:04.37CIA-7103Chris Larson <chris_larson@mentor.com> 07master * rc59070a06b 10openembedded.git/recipes/tasks/task-sdk-native.inc:
15:04.37CIA-71task-sdk-native: forgot to bump INC_PR
15:04.37CIA-71Signed-off-by: Chris Larson <chris_larson@mentor.com>
15:04.37eFfeM_workJaMa: thanks for the ack
15:04.42JaMa|Offyw
15:05.19eFfeM_workfigured as it was identical to the upstream patch an ack from you alone is ok
15:05.22ericbenkergoth_: hi, what do you think about the patch I send concerning amend.bbclass ?
15:05.25eFfeM_workwould like to get this in the weekly build
15:05.54TartarusWhen are testing tags made again?
15:06.16Tartaruswould like to see sane-toolchain + powerpc work again :)
15:06.21ericbenTartarus: friday I think
15:06.37mckoanericben: on Lenny is git version 1.6.3.3
15:06.44eFfeM_workTartarus: 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.01Tartarusok, a little time then, thanks
15:07.06*** join/#oe mickey|office (~Mickey@openmoko/coreteam/mickey)
15:07.15mckoanericben: and bitbake -b git-native fails
15:07.34mckoan~curse git-native
15:07.34ibotMay the fleas of a thousand camels infest your most sensitive regions, git-native !
15:07.37kergoth_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.50pb_hi kergoth
15:08.58kergoth_hey pb_, how's it going?
15:09.00ericbenkergoth_: 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.26pb_kergoth_: yeah, good.  cold and wet here nowadays, and starts getting dark at about 3pm, but fine apart from that :-)
15:09.27kergoth_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.32kergoth_pb_: hehe
15:09.33woglindehi
15:09.49kergoth_its lovely here, finally in the 70s(F) during the day, best part of being in arizona
15:09.51pb_kergoth_: are you expecting us to have a tsc meeting this morning?  I can't quite remember what we agreed.
15:10.15kergoth_i can't either -- i don't think i updated the meeting invite to match, so i get no reminders now
15:10.18kergoth_heh
15:10.31woglinde*g*
15:10.39Tartarusmckoan: Is there perhaps a new git subpackage yuoi need to install from debian?
15:10.46Tartaruss/yuoi/you/
15:14.10mickey|officei think we agreed to meet, but if there's nothing to discuss, we can make it end shortly
15:14.26pb_mickey|office: ok, very good
15:16.09mckoanTartarus: seems not
15:18.05*** join/#oe xobs (~smc@cm152.psi156.maxonline.com.sg)
15:18.51Tartarusmckoan: 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.32mckoanTartarus: everything worked smoothly unilt 2nd November, must be something new and untested in OE
15:23.38Tartarusmckoan: Are you sure debian didn't update their git package since?
15:23.39mickey|officeRP: ping?
15:23.41TartarusThat comes from bitbake
15:23.51kergoth_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.14mckoanTartarus: 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.37Tartarusmckoan: Well, try this
15:24.40Tartarusdo a ...
15:24.51mickey|officekergoth_: I'll take a look when I have a chance.
15:25.07Tartarusgit ls-remote http://git.senfdax.de/git/literki master
15:25.17kergoth_mickey|office: k, no rush, there's a shortage of python-fu in OE and Mentor, hard to get comments :)
15:25.27mickey|office*nod* i can imagine
15:25.37mickey|officei finally got around to writing some python again
15:25.45mickey|officeafter being buried in Vala and Objective-C for years
15:25.48kergoth_hehe
15:25.50kergoth_ncie
15:25.52Tartarusmckoan: 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.14mickey|officei still have to learn python3 though, can't motivate myself, since there's too few libraries supporting it yet
15:26.32mckoanTartarus: that command in oe tree?
15:26.49kergoth_yeah, i haven't messed with it much either, though i really want to, particularly the io changes
15:26.59mickey|officeyep
15:27.03kergoth_i did start a branch in bitbake and ran some 2to3 fixers against it, thats about it :)
15:27.05Tartarusmckoan: That's the command OE is having bitbake execute
15:27.11Tartarusmckoan: And it's a normal git command
15:27.12mickey|officei guess by mid 2011 it should get better
15:27.16mickey|officepeople are slowly adopting it
15:27.20TartarusSo have debian's git try and do it
15:27.31Tartarusor any other command in the git ls-remote man page
15:27.49kergoth_OE doesn't even technically require 2.[56] yet :|
15:27.56mckoanTartarus: 16:35 koan@quad:openembedded$ git ls-remote http://git.senfdax.de/git/literki master
15:28.00mckoanerror: git was compiled without libcurl support.
15:28.02mckoanSegmentation fault
15:28.04kergoth_ouch
15:28.09Tartarusmckoan: There you have it, debian bug
15:28.41TartarusI bet git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc also does that :)
15:28.42mckoandamn!
15:28.43Tartarustaken from the man page
15:29.34*** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net)
15:29.42kergoth_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.50kergoth_hey cminyard
15:29.59cminyardmorning kergoth_
15:30.30mckoanTartarus: thx anyway, I'll upgrade to sid
15:31.01kergoth_mckoan: i'm new to the conversation, but what's the issue with git-native?
15:31.27Tartarusmckoan: Just file a bug w/ debian
15:31.36TartarusThat's pretty clearly something that got broken :)
15:32.18mckoankergoth_: hi, see ML topic "16:24 < mickey|office> kergoth_: I'll take a look when I have a chance.
15:32.35mckoankergoth_: hi, see ML topic "Error: git was compiled without libcurl support"
15:33.01kergoth_ah
15:34.15mckoangoes back to mainstone build
15:34.35*** join/#oe dijenerate (~dijenerat@65.48.150.197)
15:37.13obithe 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.27obisee 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.37kergoth_heh, does opkg support that? :)
15:37.53obithat would become part of the introduction of the new variable, i guess
15:39.27kergoth_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.38kergoth_we have rpm as well, and there's no way everything is going to be supported by them all
15:41.59obii guess i'll prepare a patch to get some feedback from the mailing list, then
15:42.09TartarusAnd yocto has a lot of rpm work that would be good to get
15:42.19TartarusIf possible since it requires pseudo and all that
15:42.28*** join/#oe chouimat (~mathieu@kde/developer/chouinard)
15:45.58RadiooHello, someone has an idea how to fix this build error with OE: http://pastebin.com/xhZmvqQs ?
15:46.49kergoth_obi: good plan
15:47.53*** join/#oe methril_work (~methril@201.35.65.90)
15:48.18pb_what are the semantics of Breaks?  I'm not familiar with that field.
15:48.37pb_I'm fairly sure that opkg doesn't support it today but, of course, it could be made to.
15:50.49obiit indicates that the replaced package must be upgraded to continue to work, e.g. after the replacing package gets removed
15:50.56obihttp://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.04pb_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.06kergoth_damnit, __BB_DONT_PARSE seems to be biting me in the ass
16:35.08kergoth_hrm
16:36.16kergoth_oh hell, i think i see it
16:36.17kergoth_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.32Croftonanyone know where people talk about the features/improvements to gcc that come from linaro?
17:00.37woglindeon 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.18mckoanhave a nice rest of the day
17:10.58obihi 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.01eFfeMgm
17:17.14pb_obi: that patch looks sensible to me
17:20.09obiI'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.20woglindehm
17:22.23*** join/#oe blindvt (~bf@85-127-155-31.dynamic.xdsl-line.inode.at)
17:22.40woglindeI am going home now
17:22.43woglindetill 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.00blindvthi
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.49blindvteFfeM_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.10hufnus_cicqISON
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.36khemCrofton: gcc improvements are mainly on linaro mailing lists and the WG meeting minutes
18:34.52Croftonare they online?
18:34.56khemCrofton: any specific question ? I can answer too
18:35.07khemCrofton: yes. See linaro.org
18:35.31CroftonI 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.36khemCrofton: ok
18:40.01khemactually you wont find vigourous discussions compared to the number of patches but you can get some idea
18:40.09khemI personally look at the patches what they do
18:42.24CroftonI have an application that has some events I would like to use to do page up/down
18:42.38khemk
18:42.46Croftonany thoughts on how I can have user space simulate those key presses ?
18:43.12Croftonanyone can answer :)
18:43.41stefan_schmidtCrofton: libfakekey?
18:43.43khemCrofton: if you are using some GUI framework it should have such events
18:43.57stefan_schmidtCrofton: its used for virtual keyboards
18:44.35Croftonstefan_schmidt, sounds good
18:44.46Croftonthis is on gnome built in OE
18:45.17stefan_schmidtCrofton: used from the matchbox keyboard and maybe also the E17 keyboard
18:45.26stefan_schmidtshould not depend on to much gnome things.
18:45.35stefan_schmidtBut its years since I looked into it
18:45.46Croftonthanks, 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.43Croftonouoch, does svn.0-hand.com exist anymore
18:47.18stefan_schmidtCrofton: hmm, check git.o-hand
18:48.56Croftonthe 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.51cazzehi
18:59.11cazzei have problem compiling openssl-1.0.0a
18:59.20cazzeit always fails in the app directory
18:59.26cazzeis this a know problem?
18:59.33cazzeis ther a solution?
19:08.59*** join/#oe mw___ (3ff5f443@gateway/web/freenode/ip.63.245.244.67)
19:09.02mw___michaelw
19:10.09mw___i am having issues build the meta-toolchain-qte
19:10.53mw___why is it trying to access my host machine native libraries?
19:16.51blindvtCrofton, just send a key press and key release event yourself, no? think: http://paste.debian.net/100067/
19:17.19blindvtCrofton, (modulo typos and eventually missing bits)
19:17.41Crofton:)
19:17.55Croftonthanks, forwarding all these to the guy that needs to make it work
19:18.01Croftonhe's messing in python atm
19:19.05blindvtCrofton, 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.47blindvtCrofton, oops, i forgot to send the release with a KeyReleaseMask. But he'll get the idea..
19:22.55blindvtwhatever
19:24.05Jay7Packaged contents of kernel into /storage/oe/testbuilder/build/minimal/armv7/deploy/ipk/efikamx/kernel_2.6.31-r0_efikamx.ipk
19:24.07Jay7kernel-2.6.31.12-ER1
19:24.08Jay7*** Error: Package name  contains illegal characters, (other than [a-z0-9.+-])
19:24.13Tartarusyeah
19:24.16Jay7khem: no good :(
19:24.18TartarusDidn't someone else hit that yesterday?
19:24.25kergoth_yep
19:24.31TartarusCan't do ER in your version
19:24.32kergoth_khem was talking about it
19:24.37*** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey)
19:25.49Jay7NOTE: oestats: error sending task, disabling stats
19:25.51TartarusI guess upstream patches or the defconfig adds -ER1 to LOCALVERSION
19:25.54Jay7eh..
19:28.03Croftonblindvt, sounds like he has it going in python
19:33.45kergoth_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.27khemJay7: yeah I will fix it
19:35.37khemJay7: I have to patch the kernel version string
19:35.47khemkergoth_: so whats the direction?
19:36.04khemkergoth_: do we intend to branch a release ?
19:36.13Jay7khem: if possible do it before next testing branch update :)
19:36.23khemJay7: yes I will
19:37.33kergoth_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.43kergoth_khem: wait for the official word, though.
19:38.06khemhmmm. who will maintain the branch
19:38.12khemdo we have volunteers
19:38.17khemor is it one of thing
19:38.19Croftonmaintenance should be a distro issue, not an official OE task
19:38.34khemok so we branch out
19:38.41Croftonotherwise we run into the problem khem describes
19:38.49khemand release from there and distro's can then backport
19:38.56khemso essentially like stable/2009
19:39.00Croftonyeah
19:39.10Croftonbut what OE publishes is the starting point
19:39.55kergoth_we're not talking about a long lived branch here.
19:40.02khemI dont know how many folks will deliver for stabilizing release branch
19:40.02kergoth_the branch is for any stabilization *before* the release
19:40.08kergoth_the release itself is a tag from that branch
19:40.13kergoth_not a release branch after that
19:40.25khemkergoth_: you release from a tag or not
19:40.30Jay7what is purpose of testing branch then?
19:40.31khemonce you branched thats it
19:40.36kergoth_?
19:40.53khemkergoth_: I mean that becomes the maintainance thing
19:40.58kergoth_no
19:41.06khembut I think we dont have that much man power seriously
19:41.09kergoth_there will not be a maintainance branch for the release, no fixes go in after the release
19:41.19Croftonbasically, we need to try things and see what works well
19:41.23Jay7seems we going to use freebsd release logic :)
19:41.57Croftonkergoth_, but there is no objection to a distro copying from the tag and maintianing it for their puroposeds
19:42.01kergoth_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.03khemkergoth_: OK sounds fine
19:42.05kergoth_Crofton: right, exactly
19:42.30khemI see that the guy who is doing the release is the only one stabilizing
19:42.31blindvtkergoth_, 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.36kergoth_if the release person wants to go based on testing, they're free to do so
19:42.44kergoth_khem: right, thats how i see it
19:43.00Croftonsome people REALLY like the current stable branch :)
19:43.18Croftonat ELCE we talked with a couple of atmel guys who find it really useful
19:43.22kergoth_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.31Croftonlargely becuase it is very slow to change :)
19:43.54khemkergoth_: I think we wont muster enough people and time for release.
19:43.57kergoth_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.09kergoth_unless master gets merged to it periodically or something, e.g. git's maint branch
19:44.15khemkergoth_: my idea is a tag on master
19:44.21khemevery six months
19:44.56kergoth_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.57khembut branch is fine too.
19:45.03kergoth_beyond that, whatever :)
19:45.33kergoth_i think we need to sit down and establish a documented process/workflow for our branches and tags and releases
19:45.41khemyes
19:45.41kergoth_right now things are a bit too haphazard
19:45.44Jay7+1
19:46.00khemI think branch is fine. As long as devs help out on release
19:46.09kergoth_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.19khemmy only motivation to carve it out of master is the amount of developer base using it
19:46.34blindvtkergoth_, http://uclibc.org/~aldot/bitbake/20101117-1606/
19:46.57khemif devs come onboard with testing and helping out a to be released branch no problems infact its even better
19:47.03kergoth_I'd personally rather like to see something like what git does for their project, with 'next' and potentially 'pu' and all
19:47.26khemwell our master = next
19:48.07khembut I think the release branch will come into being sooner or later even if we tag master
19:48.21kergoth_which is the problem, really.  features dont get integrated together and tested as a whole other than in master itself right now
19:48.22khembecause I expect some heavy use of the release which might need bug fixes
19:48.25kergoth_which is just asking for problems
19:48.26otavioCrofton: I do think stable is useful and we depend on it here at  O.S. Systems
19:48.34khemand some distro maintainers backport stuff
19:48.42Croftonotavio, thanks
19:48.52otavioCrofton: the only problem we have is a "merge point" to "dev"
19:49.01Croftonwe get little feedback, bu that is good :)
19:49.01kergoth_blindvt: oh good, suppports always got on my nerves :)
19:49.23otavioCrofton: we would need a way to merge to "next stable"
19:49.42kergoth_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.02khemso I guess what we will do is create the release-2010.12 branch
19:50.21khemand call out for devs to pound on it
19:50.28eFfeMblindvt it is probably a good idea to go for the latest version
19:50.32eFfeMof uclibc++
19:50.37eFfeMdidn't really consider that
19:50.39khemmay be using the testing matrix
19:50.39blindvtkergoth_, bummer, i totally forgot about oe.path. Yea, perhaps that's a good idea
19:50.51kergoth_blindvt: second, ud.parm.get('md5sum', None) -> None is the default for the second argument, you can just ud.parm.get('md5sum')
19:51.01eFfeMguess the patches are not in htat version either, there are really only a few commits since the 0.2.2. release
19:51.09eFfeM(5-10 iirc)
19:51.21otaviokhem: if there's any "new" release (stable or whatever) please merge it back into dev from time to time
19:51.30otaviokhem: so we have "merge points" at it
19:51.34khemotavio: it wont be merged
19:51.43khemotavio: patched should be always backported
19:51.51khemto it via master imo
19:51.51otaviokhem: so it will always be a nightmare
19:52.07Jay7freebsd or pkgsrc release process is alike
19:52.13khemotavio: and 6 months down the line we will have next release
19:52.20kergoth_blindvt: also you have a remnant commented out line in fetch/svn.py, first hunk in the last patch
19:52.20Croftonotavio, that is  hard problem due to core changes in dev
19:52.21khemand then this release is decommissioned
19:52.22Jay7pkgsrc does release quarterly
19:52.27kergoth_blindvt: other than that, they look sane to me
19:52.53Jay7freebsd have stable and current branches (like our)
19:53.10blindvteFfeM, 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.47Jay7I like pkgsrc scheme
19:54.03blindvtkergoth_, yes: '#logger.warn("You should switch to SRCREV")'
19:54.05kergoth_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.06Jay7split branch quarterly, stabilize it and announce release
19:54.12kergoth_s/module/package/
19:54.16Jay7then return to work on master
19:54.32Jay7release branches are subject to security updates only
19:54.38blindvtkergoth_, 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.45kergoth_ah
19:55.08otavioCrofton: no related stuff
19:55.09kergoth_probably not a bad idea
19:55.17blindvtkergoth_, i didn't runtime test anything of that and i didn't want to spit out odd/outdated/misplaced warnings
19:55.19otavioCrofton: if backports are done into release
19:55.23kergoth_nods
19:55.31otavioCrofton: release ought to "merge" fine into dev
19:55.45kergoth_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.48otavioCrofton: and merging it into dev provides an upgrade path for next stable
19:55.51kergoth_heh
19:55.52Croftonthis is why I see people developing their own concpet of "stable"
19:56.38otavioCrofton: for us, for example, move to next OE is a nightmare since we have too many conflicts to deal with
19:56.41blindvtkergoth_, 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.41khemotavio: This release we will should try to always commit to master and then backport to release branch thats upto disto maintainers
19:56.45eFfeMkhem, please see my reply on the uclibc++ mail, the error messages are in the original mail and in the reply
19:56.57khemif there is a patch thats only needed on release and not on master then thats fine
19:57.06khembecause the patch is dead anyway
19:57.10otaviokhem: right but only doing this doesn't make it work
19:57.18otaviokhem: we need to merge release back into master
19:57.30khemotavio: I dont get it
19:57.38otaviokhem: since master will contain all changes of release it will just work
19:57.41Jay7we can just release more frequently
19:57.43JaManeither do I
19:57.47Jay7fire and forget :)
19:57.48khemif you branch out and all commits to this branch come via master what do u need to merge back ?
19:57.55blindvtkergoth_, 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.12otaviokhem: OK... let me try to explain
19:58.13khemotavio: but master will have other shitload
19:58.19khemthat can bite you in the ass
19:58.19Jay7I see this is only way for OE at this time because nobody cares about stable
19:58.25kergoth_blindvt: push after making the changes i proposed? :)
19:58.33CroftonJay7, that is not true
19:58.56kergoth_blindvt: take a look at https://github.com/kergoth/bitbake/compare/master...parallel-parsing-prep, thoughts?
19:59.01khemJay7: only way to enlarge userbase is to have releases
19:59.15otavioLet me try to make it clear.
19:59.22Jay7khem: yes, sure
19:59.25otavioOE releases 2010.12
19:59.39otavio<PROTECTED>
19:59.50otavio<PROTECTED>
19:59.52khemCrofton: yes thats true
20:00.02otavio<PROTECTED>
20:00.09*** join/#oe kristoffer (~kristoffe@c-a3dee555.010-30-6c6b7012.cust.bredbandsbolaget.se)
20:00.13CroftonI have received very positive feedback from suers
20:00.24otavio<PROTECTED>
20:00.43Jay7otavio: how to deal with core changes?
20:00.44Croftonwhere users is defined as people doing work with the output of OE
20:00.50blindvtkergoth_, which proposed changes? 1) enable the warning -- scheduled for the next oe build. 2) what?
20:01.04Jay7e.g. changing required bitbake (and python) versions
20:01.19Jay7or changing metadata behaviour like new staging
20:01.25kergoth_blindvt: add oe.path.join to bb.utils and use that, drop the unnecessary ", None" in that ud.parm.get for md5sum
20:01.39khemotavio: why should release is merged back into master
20:01.42JaMaotavio: so every commit which was cherry-picked to release will be twice on master?
20:01.45Jay7release is point, not branch :)
20:01.59blindvtkergoth_, k
20:02.26JaMaotavio: 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.58otavioJaMa: yes. Or we commit into release and merge it into master
20:02.59Jay7we should define 'release' and 'branch from release was made'
20:03.04Jay7*from which
20:03.24Jay7thats are different things..
20:03.29JaMaotavio: probably first to master to provide some testing before cherry-picking to release
20:03.41blindvtkergoth_, 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.50otaviousually maintainence branches receive fixes that are merged into development one when done
20:04.05otavioJaMa: but then there's no path to upgrade to master again
20:04.11kergoth_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.21khemotavio: no merge into release it gets the patches from master that way we make sure that all fixes go into master
20:04.28khemand are there in next release
20:04.34otavioJaMa: if you try: git merge stable/2009 into master you'll see the nightmare it is
20:04.38kergoth_uses it all the time to avoid having to catch a KeyError or check for existence first
20:04.47blindvtkergoth_, indeed
20:04.50khemthen they are cherry picked into release even though the fix is only for release
20:05.44khemotavio: 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.50khemOE changes frequently
20:06.17khemand sometimes changes are fundamental
20:06.24otaviokhem: how do you suggest to a company to "fork" from main OE and have an upgrade path for next release then?
20:06.34JaMaotavio: why not cherry-pick commits from your branch to new "release" and resolve only those (with needed changes due different core)?
20:06.45kergoth_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.51blindvtkergoth_, 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.53khemgives up and thinks just make the release happen and stop thinking beyond that
20:07.14kergoth_blindvt: iirc PEP8 advises one import per line
20:07.20obiotavio: i think the "nightmare" comes from changing files for your fork and not submitting the changes for inclusion into master
20:07.21khemotavio: w.r.t. internal changes ?
20:07.23kergoth_i'd say be explicit about what you're using, don't rely on indirect imports
20:07.31obiotavio: maybe using abb layer would help
20:07.34khemotavio: the next release will be another branch
20:07.46*** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox)
20:07.49khemand it will have all fixes that were done to previous release
20:07.57blindvtkergoth_, k. Just asking since alot of spots rely on indirect imports of os.path (IIRC)
20:08.00khemso your next product can base of this branch
20:08.36kergoth_blindvt: oh, i see what you mean
20:08.45otavioobi: partially yes. But not really.
20:08.47kergoth_for that particular case, where the package imports one of its own modules, you can rely on that
20:08.57kergoth_an import of just os will get you os.path
20:09.06kergoth_now, if you only use os.path, nothing else in os, i'd say just import os.path
20:09.15kergoth_imo anyway
20:09.17khemotavio: I guess you have to stabilize on a release
20:09.25khemand next release
20:09.26blindvtkergoth_, ok
20:10.06kergoth_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.16otaviokhem: but not using a git tree. Using a layer?
20:10.25khemotavio: 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.29blindvtkergoth_, one last thing: this one's still open (from earlier today):
20:10.33blindvtkergoth_, 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.44khemotavio: yes layer is better
20:10.56kergoth_blindvt: i think that should likely wait until the fetch revamp
20:10.59otaviokhem: we use a git tree currently
20:11.05khemotavio: unfortunately there is no OE standard like ISO C standard that we comply to
20:11.09kergoth_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.10otavioneeds to learn how to work with layers
20:11.12khemso things change
20:11.20blindvtkergoth_, i see
20:11.30kergoth_the whole archival of scms may change entirely, or become optional just for mirroring purposes
20:11.53khemotavio: yeah layers can give you better view of minimizing the changes to OE metadata
20:12.12otaviokhem: after the meeting can we talk about this ?
20:12.13khemand then when you upgrade to newer release you have to port forward your layers only in ideal case
20:12.14blindvtkergoth_, i'll have a look at your parallel-parsing-prep if i find the time
20:12.21kergoth_blindvt: np, no rush
20:12.27kergoth_just need a sanity check :)
20:12.42kergoth_e.g. am i completely out of left field, or is this a real improvement to the code
20:12.44blindvtfigured :)
20:13.03*** join/#oe anarsoul (~anarsoul@80.249.95.238)
20:13.20khemotavio: which meeting ?
20:13.42otaviokhem: well, I don't want to disturb asking questions now
20:14.04khemotavio: sure.
20:15.16blindvtkergoth_, 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.57blindvts/poke/look/
20:15.59kergoth_blindvt: i dropped the class changes and was able to build xz and xz-native fine on my machine and configuration, anyway
20:16.05kergoth_i didn't dive any further than that, though
20:16.21kergoth_has so many bitbake and oe trees/branches he's in real danger of forgetting where he was doing things
20:16.36kergoth_https://gist.github.com/700677
20:16.38kergoth_heh
20:17.44kergoth_meh
20:17.45blindvti'm interrested in feature/typing! perhaps that one can fix my keyboard -- or myself for that matter :P
20:17.51kergoth_hehe
20:17.53kergoth_if only it meant that
20:22.23blindvtkergoth_, 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.54kergoth_feel free to push it with the strip slash bits now and revisit later if you want
20:23.03blindvtk. thanks
20:23.03kergoth_i know how you feel
20:23.05kergoth_np
20:23.33kergoth_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.02blindvtkergoth_, at least i can get rid of local stuff i accumulate in bb. That's a good start :)
20:24.05kergoth_nods
20:25.26blindvtgiven the rate that i can trick khem into applying stuff to oe there's a long way to go, but hey
20:25.59khemblindvt: you just have to make less controversial patches :)
20:26.28kergoth_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.05blindvtkhem, they're useful or make stuff work
20:27.08Jay7autobuilder can solve this :)
20:27.25Jay7at least check that your changes doesn't break building
20:27.32kergoth_yeah
20:27.55Jay7let's ask Amazon to donate cloud for OE :)
20:27.59cazzecan somebody help me build openssl-1.0.0a?
20:28.12cazzei get errors in the app dir
20:28.14Jay7then build some kind of autobuilder/tinderbox there :)
20:28.45blindvtkhem, 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.55Jay7or even let's ask Intel/AMD directly for build farm :)
20:29.34cbrakewith 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.39khemblindvt: ppc works fine in OE
20:30.28*** join/#oe Jordinar (~Jord@77-20-67-155-dynip.superkabel.de)
20:31.37Jay7I can add build request interface for my home machine
20:31.45JordinarHas someone an idea what's wrong here with mtd-utils_1.3.1.bb - http://pastebin.com/xhZmvqQs ?
20:31.45khemcbrake: 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.58Jay7to allow build request queueing
20:32.09khemcazze: paste your issue somewhere
20:33.45ericbencbrake: here with PARALLEL=16 and BBTHREAD=4 the i7 gets quite loaded ;-)
20:34.36khemJordinar: your objdir looks suspicious
20:34.57blindvtkhem, qemuppc didn't build for me last time i tried. How did you build libstdc++-v3 without support for long-double-128?
20:34.59khemJordinar: the issue is that the files are compiled for some other arch and are being linked into some other
20:35.19khemblindvt: well it build now
20:35.36khemblindvt: thre is ofcourse one patch from Tartarus that should go in
20:35.46khemwhich 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.41Jordinarkhem: 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.13khemJordinar: what does your local.conf look like
20:37.40blindvtkhem, 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.45kergoth_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.23cbrakehmm, 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.37Jordinarkhem: that's all: http://pastebin.com/eCMnrzVg
20:39.07khemblindvt: except I use gcc 4.5
20:39.09*** join/#oe Martin_B (~martin@pool-21-67-198-89.dbd-ipconnect.net)
20:39.11khemand minimal-uclibc
20:39.48Jay7cbrake: 1) may be you building something that just have no load for 16 threads; 2) may be some changes in kernel scheduler
20:39.51JaMafor me micro+eglibc didn't somehow stage stdio.h and eglibc-initial failed to do_configure bacause of it :/
20:40.08khemJordinar: you dont need to set TARGET_OS
20:40.33khemJaMa: since when ?
20:40.48*** join/#oe Martin__B (~martin@pool-21-67-198-89.dbd-ipconnect.net)
20:40.49khemJaMa: I think some folks do use micro
20:40.58khemand dont see this
20:41.07JaMano idea this was actually my first micro build (just to test that binconfig change I've sent to ML)
20:41.36khemblindvt: anyway take latest OE apply http://patchwork.openembedded.org/patch/3565/ and qemuppc should work
20:41.57Jay7btw
20:42.18Jay7khem: ack changes for sh3/4 or push it :)
20:42.23khemJay7: you have my ack for that
20:42.27blindvtkhem, yuck
20:42.29JaMakhem: I suspected my patch and then 6f5c792dd75746009e7a5994170cec05a92f0fdd, but even after reverting those 2 It still failed
20:42.35Jay7ok, I'll push it then
20:42.40Jordinarkhem: "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.54khemJordinar: I think OE is overriding that for you
20:43.59khemso not an issue here
20:44.35cazzekhem: http://pastebin.com/EJy08CmH
20:44.52khemJordinar: but this path is fishy /home/radi/oe/build/minimal/mkfs.ubifs/crc16.o
20:44.54Jordinarkhem: alright, mtd-utils still fails... bad, but thanks for your help
20:45.19khemJordinar: 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.59Jordinarkhem: 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.03khemcazze: it seems its needing crypto
20:47.24Jordinartools for writing to flash, etc.
20:47.50khemJordinar: 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.15cazzekhem: so bitbake crypto will do the job?
20:48.18khemJordinar: are they cross tools
20:48.25khemcazze: no
20:48.36khemcazze: its expecting it be on your host
20:48.44khemits openssl-native not openssl
20:48.56Jordinarkhem: they definitely end there using 'bitbake minimal-image' ... without changing the scripts etc.... only local.conf is modified.
20:49.32cazzekhem: i will thest, thx already for the help
20:49.36cazze*test
20:49.44Jordinarkhem: no, the binaries there run fine on the buildhost (x86)
20:50.39Jordinarcould be an error in the mtd-utils*.bb ?
20:50.46khemJordinar: hmmm I see. so those are for host but why are they being linked into target packages I wonder
20:50.55khemJordinar: its possible
20:51.08khemsee 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.18cazzekhem: 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.10Croftonkhem, do you mind if I push the patch I posted on the list yesterday?
21:13.29Croftonand 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.53Croftonif I REDEPEND on pkgconfig-dev, do I need to DEPEND on pkgconfig?
21:20.22khemCrofton: sure go ahead
21:20.30Croftonk
21:20.31kergoth_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.44khemCrofton: 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.55khemthen we might be able to cut a release branch soon
21:21.06CroftonI posted the one, both should not have broad impact
21:21.26khemJordinar: I will see if I can get around to reproducing it
21:21.48khemJordinar: but problem is basically the same what  Iexplained somehow linker is searching wrong libs/objects
21:22.32Jordinarkhem: yeah, I agree .... but I really don't know where to tamper in the oe files to fix that
21:22.34khemcazze: 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.46khemJordinar: ok np
21:22.59JordinarI guess that nothing should write its stuff to build/minimal ..... that's what it does here
21:23.00khemJordinar: you can summarize the issue on mailing list
21:23.11khemthat will serve as reference for offline work
21:23.30khemI dont know if I can but if I do come around with some time I will try to fix it
21:23.56Jordinardidn't work much with lists ..... just writing an email with the info to ..... ?
21:24.20khemlook at openembedded.org
21:24.45Jordinaric.
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.20khemkergoth_: I have a patch but I have do_patch overridden
21:32.43khemkergoth_: so I want to copy this patch into workdir but as a normal file and then apply myself
21:32.56kergoth_;apply=no
21:33.00khemkergoth_: apply=no and what other attribute
21:33.02khemok
21:33.07kergoth_hmm
21:33.14kergoth_it *should* unpack a patch that's set to apply=no
21:33.17kergoth_but verify that :)
21:33.31khemanother problem is that I have patches/ folder being overwritten so its better to keep it on topdir
21:33.54khemhmmm I think I have hijacked unpack too
21:34.06khemso basically I have to manually symlink it
21:36.58*** join/#oe redguy (~matik@unaffiliated/redguy)
21:37.18kergoth_heh
21:39.48*** join/#oe angelox_123 (~Angelo@201-43-66-8.dsl.telesp.net.br)
21:43.30CIA-7103Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * rc149a3e6f7 10openembedded.git/recipes/tasks/task-mythtv.bb:
21:43.30CIA-71task-mythtv: new task to aggregate mythtv related packages
21:43.30CIA-71Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
21:43.32CIA-7103Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r1ff4b0a7bf 10openembedded.git/recipes/mythtv/mythplugins_0.23+fixes.bb:
21:43.32CIA-71mythplugins_0.23+fixes.bb: improved installation, commented out apache stuff
21:43.32CIA-71commented out apache stuff; apache has too many issues building
21:43.32CIA-71use lighttpd!
21:43.32CIA-71improved the postinst, make sure the needed modules are enabled
21:43.32CIA-71in the web server configuration file
21:43.33CIA-71Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
21:43.33CIA-7103Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r537f94646e 10openembedded.git/recipes/images/james-image.bb:
21:43.34CIA-71james-image: image for the james, a home entertainment solution
21:43.34CIA-71see http://www.elinux.org/BeagleBoard/James for outdated doc
21:43.35CIA-71will be updated (and maybe relocated) in the future
21:43.46CIA-71Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
21:43.47CIA-7103Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r669a9b9c0a 10openembedded.git/recipes/tasks/task-internetserver.bb:
21:43.49CIA-71task-internetserver: task to aggregate internet server functionality
21:43.50CIA-71apache/php/mysql/perl/ftp
21:43.50CIA-71other servers might be added in due time
21:43.50CIA-71Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
21:43.50CIA-7103Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r12d3b6eaf3 10openembedded.git/recipes/gtkmm/ (5 files):
21:43.50CIA-71gtkmm: added gtkmm-demo package
21:43.51CIA-71There were some unpacked files in /usr/share/gtkmm-2.4/demo/
21:43.51CIA-71This patch addes a new package gtkmm-demo and stuffs the files from
21:43.52CIA-71that demo dir in it
21:43.52CIA-71Also added INC_PR
21:43.53CIA-71Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
21:45.06CIA-7103Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * rde524aeeec 10openembedded.git/MAINTAINERS:
21:45.07CIA-71MAINTAINERS: added james-image + tasks to my entry
21:45.07CIA-71Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
21:51.02TartarusHmm
21:51.12TartarusIs 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.29eFfeMTartarus: the testing page has some
22:00.41eFfeMnslu2le/be slugos slugimage iirc
22:00.49Tartarusah right
22:00.50eFfeMcalling it a day, cya all tomorrow & have fun!
22:00.53Tartaruslater
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.11blindvtkhem, 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.16blindvtkhem, TIA
22:12.43blindvtdrats
22:12.50blindvtkhem, 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.12blindvt(fixes typo in commit message of commentary typo fix of sample conf ;)
22:13.22Jay7https://spreadsheets.google.com/ccc?key=0AhY8lmfkCabTdFlPQ1ozR2ZNM0Z4ckpLZ3VOLVE2dnc&authkey=CKy8lbkH#gid=0
22:13.27Jay7vmstat graph
22:13.39Jay7ka6sox-work: ^^
22:14.55*** join/#oe NTU (~ntu@unaffiliated/neo-the-user)
22:16.19khemblindvt: thx will do
22:16.28*** join/#oe redguy (~matik@unaffiliated/redguy)
22:17.05blindvtkhem, 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.36khemblindvt: fantastic.
22:18.44khemblindvt: how is life ?
22:19.02khemblindvt: geared enugh for a uclibc release yet?
22:19.18*** join/#oe redguy (~matik@unaffiliated/redguy)
22:19.20blindvtkhem, pfff. This one was a pretty bad year in RL for me
22:19.56khemblindvt: I understand
22:21.34*** join/#oe redguy (~matik@chello089076237104.chello.pl)
22:21.34*** join/#oe redguy (~matik@unaffiliated/redguy)
22:22.05blindvtkhem, 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.04Tartarus<PROTECTED>
22:23.13*** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net)
22:23.16TartarusIsn't gobject-introspection stuff supposed to be disabled?
22:23.30kergoth_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.33khemblindvt: ok .32 is fine too
22:30.41khemblindvt: I want nptl out of door
22:31.02khemand it will be first version with nptl so .32 is fine as it crystalizes
22:31.11khemwe can have 1.0 release
22:31.48blindvtkhem, 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.30blindvtkhem, 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.11blindvtkhem, 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.43blindvtok. i'll send the ext4 image stuff tomorrow.
22:40.52blindvtg'night, all!
22:44.26CIA-7103Yuri 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.09Jay7hm..
22:53.29*** join/#oe GNUtoo|laptop (~gnutoo@95.232.144.102)
22:53.40khemblindvt: 4.6.0 should happen next year
22:53.49khemblindvt: we worry about it then
22:54.50khemblindvt: honestly uclibc has been neglected on my part for past few months
22:55.36Jay7should I check Archived checkbox in patchwork?
22:55.39Jay7what this mean?
22:57.54*** join/#oe ant__ (~andrea@host252-254-dynamic.31-79-r.retail.telecomitalia.it)
22:59.55khemJay7: yes its stored
23:00.18ant__hey khem
23:01.22Jay7applied then
23:01.31*** part/#oe angelox_123 (~Angelo@201-43-66-8.dsl.telesp.net.br)
23:02.27khemant__: hi
23:03.10ant__angstrom-eglibc for armv5te has just built fine
23:03.27ant__we should really move to eglibc per default
23:03.51ant__I'll compare the sizes
23:03.56CIA-7103Khem Raj <raj.khem@gmail.com> 07master * reb6a1aa091 10openembedded.git/recipes/linux/ (3 files in 2 dirs):
23:03.56CIA-71linux-efikamx: Fix the existing 2.6.31 recipe to use lower case letter in package name
23:03.56CIA-71* Use upstream Amit's branch for git recipe
23:03.56CIA-71Signed-off-by: Khem Raj <raj.khem@gmail.com>
23:04.02Tartaruscurses, quite loudly, scripts that do @python@, @perl@ and so forth
23:04.04khemant__: angstrom-2010 uses eglibc by default already
23:04.08CIA-7103Khem Raj <raj.khem@gmail.com> 07master * ra6e303aed1 10openembedded.git/recipes/eglibc/ (eglibc_2.11.bb eglibc_2.12.bb eglibc_svn.bb):
23:04.09CIA-71eglibc_2.11/eglibc_2.12/eglibc_svn: Upgrade to latest SVN tip
23:04.09CIA-71Signed-off-by: Khem Raj <raj.khem@gmail.com>
23:04.11CIA-7103Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> 07master * rd53f2eaae3 10openembedded.git/conf/local.conf.sample:
23:04.11CIA-71local.conf.sample: commentary typo fix
23:04.11CIA-71Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
23:04.11CIA-71Signed-off-by: Khem Raj <raj.khem@gmail.com>
23:04.12CIA-7103Khem Raj <raj.khem@gmail.com> 07master * rf5c7beb6f5 10openembedded.git/conf/distro/minimal.conf:
23:04.12CIA-71minimal.conf: Pin QT version to 4.7.0
23:04.12CIA-71Signed-off-by: Khem Raj <raj.khem@gmail.com>
23:04.14CIA-7103Tim Harvey <harvey.tim@gmail.com> 07master * r2c2013c90f 10openembedded.git/recipes/nuttcp/ (nuttcp/nuttcpd.init nuttcp_7.1.3.bb):
23:04.14CIA-71nuttcp: new recipe
23:04.14CIA-71Signed-off-by: Tim Harvey <harvey.tim@gmail.com>
23:04.14CIA-71Signed-off-by: Khem Raj <raj.khem@gmail.com>
23:04.16CIA-7103Graham Gower <graham.gower@gmail.com> 07master * rec8e3903c1 10openembedded.git/conf/distro/include/sane-toolchain.inc:
23:04.16CIA-71sane-toolchain.inc: remove duplicate line.
23:04.16CIA-71Signed-off-by: Graham Gower <graham.gower@gmail.com>
23:04.16ant__he..I'm working on 'stable' ;)
23:04.23Tartaruskhem: Are you sure gcc 4.4.4 + powerpc breaks?
23:04.28khemTartarus: yes
23:04.29TartarusI didn't get that same fatal error
23:04.36TartarusAt least no quite so quick, but k
23:04.41TartarusWant me to re-sub?
23:04.43khemTartarus: err
23:04.45TartarusOr just update
23:05.03khemTartarus: update add my sign-off and push
23:05.25khemTartarus: better you push today tomorrow we will have another test branch
23:05.34Tartarusyeah
23:05.43khemJay7: now efikamx kernel should build fine
23:05.49khemJay7: try that out
23:05.57TartarusNeed to, ahem, bitchslap gobject-introspection real quick too
23:06.27ant__khem: still I'm tempted by uclibc..how is the NPTL status?
23:06.37khemtwo more bike rides to work and then I have 20 dollars gift card
23:06.42ant__have you unified the recipes?
23:06.54Jay7khem: thanks, I'll restart efika builds this night
23:06.57khemant__: it is or was good last time I did stuff
23:07.32khemant__: arm/ppc/mips/sh/x86/x86_64 support nptl and seem to work to some extent
23:07.38ant__iirc uclibc-git was needed for nptl
23:07.59khemant__: yes the reason for that is because there is no uclibc release yet with nptl
23:08.10ant__oh, I see...
23:08.11khemsoon we may have .32
23:08.21khemthen that will be first official nptl release
23:09.38*** join/#oe dth_ntb (~dth@a89-183-11-169.net-htp.de)
23:12.01CIA-7103Camille Moncelier <moncelier@devlife.org> 07master * rcf67dc1bb1 10openembedded.git/recipes/dropbear/ (dropbear.inc dropbear/default):
23:12.01CIA-71dropbear: Removed openmoko references. Added /etc/default/dropbear
23:12.01CIA-71Signed-off-by: Camille Moncelier <moncelier@devlife.org>
23:12.01CIA-71Signed-off-by: Khem Raj <raj.khem@gmail.com>
23:14.35*** join/#oe guufy (~Guufy@70-35-57-218.static.wiline.com)
23:15.25CIA-7103Maksym Parkachov <lazy.gopher@gmail.com> 07master * r04531031ee 10openembedded.git/recipes/mcpp/ (mcpp.inc mcpp_2.7.2.bb):
23:15.26CIA-71mcpp: added new recipe for version 2.7.2
23:15.26CIA-71* created .inc file for both target and native version
23:15.26CIA-71* added version 2.7.2
23:15.26CIA-71Signed-off-by: Maksym Parkachov <lazy.gopher@gmail.com>
23:15.26CIA-71Signed-off-by: Khem Raj <raj.khem@gmail.com>
23:16.44obikhem: 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.47obiit's a build fix, but not many people seem to care
23:17.54khemobi: patch looks sane to me
23:18.17khemlet me pull it into my tree where I will launch a clean build now
23:18.21TartarusThe .pc one?
23:18.25obithanks
23:18.26TartarusWhat is broken today?
23:18.28khemobi: do u have patches pending on this patch
23:18.29obiTartarus: yes
23:18.46CIA-7103Tom Rini <tom_rini@mentor.com> 07org.openembedded.dev * r4e5f9e1010 10openembedded.git/conf/distro/include/ (sane-toolchain-eglibc.inc sane-toolchain-glibc.inc):
23:18.46CIA-71sane-toolchain-*glibc.inc: Use -O2 on PowerPC
23:18.46CIA-71In FULL_OPTIMIZATION use -O2 on powerpc due to some problems
23:18.46CIA-71with libgcc.a and -Os when using gcc 4.5.x.
23:18.46CIA-71Signed-off-by: Tom Rini <tom_rini@mentor.com>
23:18.46CIA-71Acked-by: Khem Raj <raj.khem@gmail.com>
23:19.08obikhem: 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.33Tartaruskhem: Bah
23:19.38Tartarusdidn't update commit msg, did update comment
23:19.49khemTartarus: thats ok :)
23:19.59obiTartarus: well, it's described in the commit:
23:20.02khemcomment is more important
23:20.04obi"* .pc files must be installed explicitly to avoid causing
23:20.04obi<PROTECTED>
23:20.04obi<PROTECTED>
23:20.04obi<PROTECTED>
23:20.26Tartarusobi: That makes more sense with your overlay msg above
23:20.28obitoday, pkgconfig.bbclass does a recursive search for *.pc and installs every file it can find
23:20.28TartarusWhich isn't :)
23:22.02obiactually, it depends on the packages you want to use
23:22.22Jay7hehe.. opie-notes fails to build by gcc-4.5
23:22.31Jay7as I understand at least
23:22.55Jay7it builds ok for angstrom but fails for minimal
23:23.02khemJay7: lot of opie recipes dont build with gcc 4.5
23:23.24khemthere was a new release coming I guess which is more modern C++
23:23.28obiTartarus: 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.30khemchances of that working is better
23:23.45Jay7so, opie-image cant be built for minimal distro
23:23.55khemI think using standard install for .pc files is sufficient
23:24.30Jay7is thinking how to describe this better on testing page..
23:25.02Tartaruswell, angstrom isn't gcc 4.5 is it? :)
23:26.53khemTartarus: angstrom-2010 is
23:27.33khembut i think angstrom is more and more geared to ARM these days
23:28.55khemJay7: whats the error
23:29.04Jay7http://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.32Jay7khem: angstrom have similar messages but as warnings and for other files
23:30.24Jay7an, ant__ pointed me to warnings for mainwindow.cpp too
23:31.08ant__yep, only warningswith old gcc
23:31.37Jay7btw, other problem of oestats - you can't return from log view to build view
23:32.07Jay7I should collect this somewhere in preparation for oestats-next :)
23:32.45ant__khem: http://pastebin.ca/1995077
23:33.25ant__he..O2 vs. Os too
23:33.48ant__we need runtime testers :p
23:34.30khemJay7: yeah I have seen that error. Its a warning from newer compilers
23:34.45khemJay7: I have fixed few things in OE to shush this warning
23:34.52khembut was not interested in opie
23:36.05khemant__: that code needs to be fixed
23:36.45ant__yes, starts to bitrot
23:39.03Croftonopie does not have any momentum
23:39.54Croftonangstrom is "geared" to what people ask for and work on
23:40.14CIA-7103Tom Rini <tom_rini@mentor.com> 07org.openembedded.dev * r8d906dfca2 10openembedded.git/recipes/gobject-introspection/ (2 files in 2 dirs):
23:40.14CIA-71gobject-introspection: Use /usr/bin/env for python
23:40.14CIA-71Scripts that do #!@PERL@ or #!@PYTHON@ and replace that with
23:40.14CIA-71a full path are in danger of breaking in certain environments
23:40.14CIA-71(such as some autobuilders) and should instead use /usr/bin/env.
23:40.15CIA-71While in here, use GNOME_MIRROR for the sources.
23:40.16CIA-71Signed-off-by: Tom Rini <tom_rini@mentor.com>
23:42.52Jay7well..
23:43.01Jay7have updated Testing page..
23:43.04ant__Crofton: Opie happens to produce small working images, though severely outdated
23:43.19ant__it attracts more users to #oe
23:43.23ant__;)
23:43.27Jay7* usable images :)
23:43.49Croftonsure
23:44.14Croftonbut is outdated
23:44.20Croftonand hard to keep up in dev
23:44.32ant__well, yes and not
23:44.40ant__bluelightning is doing miracles
23:44.47Jay7very useful to use on outdated hardware :)
23:45.31ant__still, two core recipes with legacy staging need love...
23:46.19Jay7it would be great to remove legacy staging before release..
23:46.24Jay7but seems too late now
23:46.44ant__thought about giving 'sugar' distro to his 3yrs old kid...
23:46.57ant__while I thought he stole my iphone
23:47.00ant__:/
23:47.16ant__that's about ease of use
23:47.38Jay7Testing page source is about ease of use :\
23:47.50Jay7even for me already..
23:48.15Jay7I'm thinking about splitting table by distro
23:48.28Jay7or by machines
23:48.41ant__he..we come back to the damned matrix
23:48.50Tartarusgoogle form :)
23:48.56Jay7yeah..
23:49.01TartarusAnd that was essentially the point I was trying to make
23:49.09TartarusDid my first builds and report the other week
23:49.20TartarusAnd yeah, I wanted to improve the wiki part
23:49.23Tartarussince it was kinda painful
23:49.40Jay7dokuwiki tables syntax is more elegant...
23:49.53Jay7but with such big table it will suxx anyway
23:50.15Tartarusanything without actually 90% working graphical editing is a pain
23:50.30TartarusAnd then it's just a slightly different pain :)
23:50.59Jay7can mediawiki use FCKeditor or TinyMCE?
23:51.08Jay7both have tables support iirc
23:51.22Jay7my drupal and typo3 installations have it at least
23:55.57*** join/#oe playya__ (~playya@unaffiliated/playya)
23:57.55ant__btw, any idea about this recuyrrent notes?
23:57.57ant__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.24ant__this is first occurrence
23:58.25Tartarusit's still vaugely on my list to work out
23:58.38ant__long standing issue
23:58.56ant__other is the 'inherit gettext'
23:59.05Jay7khem: I've started minimal/efikamx/console-image build
23:59.12*** join/#oe xobs (~smc@cm152.psi156.maxonline.com.sg)
23:59.23ant__well, Missing inherit gettext?

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