00:01.54 | *** join/#oe sgw (~sgw@134.134.137.71) |
00:03.35 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * rdbc0cf9701 10bitbake.git/lib/bb/server/process.py: |
00:03.36 | CIA-47 | server: add profiling support to ProcessServer |
00:03.36 | CIA-47 | Based on poky's support, particularly the format of the processed log file and |
00:03.36 | CIA-47 | the log message shown to the user regarding the files written. |
00:03.36 | CIA-47 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
00:07.29 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * rcd43144f0f 10bitbake.git/lib/bb/server/process.py: |
00:07.29 | CIA-47 | server: clean up call of write_profile_stats |
00:07.29 | CIA-47 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
00:18.31 | *** join/#oe mrc3 (~ddiaz@189.157.117.151) |
00:19.29 | *** join/#oe sgw (~sgw@134.134.137.73) |
00:27.46 | mwester | Question on the upcoming release -- are commits to the mainline being merged into the release, or do I have to make arrangement to have that happen? |
00:29.42 | Tartarus | We haven't branched, yet |
00:29.49 | Tartarus | I guess I hadn't made that clear enough, sorry |
00:30.02 | mwester | I probably didn't read closely enough. |
00:30.25 | mwester | That's good news then -- I shall continue on stabilization rather than SlugOS features. :) |
00:30.33 | Tartarus | Did you see [oe] 2011.03 release testing, starts soon! ? |
00:32.10 | mwester | Yep - I checked the matrix you emailed out. |
00:35.45 | *** join/#oe mrc3 (~ddiaz@189.157.110.169) |
00:37.09 | Tartarus | I wasn't clear enough in there then, another email sent out :) |
00:37.17 | Tartarus | You've got at least until the 24th ;) |
00:46.38 | *** join/#oe rsalveti` (~rsalveti@201.82.72.101) |
00:52.59 | *** join/#oe Jefro (~josiermi@134.134.139.76) |
01:15.03 | *** join/#oe mrj10 (~mrj10@63.252.64.254) |
01:42.59 | *** join/#oe _julian (~quassel@hmbg-4d06ac6b.pool.mediaWays.net) |
02:00.23 | *** join/#oe mrc3 (~ddiaz@189.157.114.48) |
02:12.13 | *** join/#oe mrj101 (~mrj10@63.252.64.254) |
02:53.49 | Tartarus | No one fix the db RPATH issues yet? |
02:57.43 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
03:00.10 | *** join/#oe sgw1 (~sgw@134.134.139.74) |
03:01.23 | CIA-47 | 03Tom Rini <tom_rini@mentor.com> 07org.openembedded.dev * r2d615a19a6 10openembedded.git/recipes/linux/linux-2.6.30/at91/ (3 files): |
03:01.23 | CIA-47 | Revert "Remove some patches, which was moved by previous linux patch" |
03:01.23 | CIA-47 | I pulled this patch in prematurely which broke the at91 machines, |
03:01.23 | CIA-47 | so back this out. Sorry folks! |
03:01.23 | CIA-47 | This reverts commit cfa8a2a8b291cb0a3426a3120ce31e6e74970e37. |
03:01.38 | *** join/#oe fraxinath (~quassel@pD9536E05.dip.t-dialin.net) |
03:02.34 | *** join/#oe Jefro (~josiermi@nat/intel/x-rpkokxjytionuvnn) |
03:23.06 | *** join/#oe mrc3 (~ddiaz@189.157.108.186) |
03:48.36 | *** join/#oe sgw (~sgw@134.134.137.71) |
04:54.43 | *** join/#oe Jefro (~josiermi@nat/intel/x-isaqgiwmudlpmbrq) |
05:11.02 | CIA-47 | 03Tom Rini <tom_rini@mentor.com> 07org.openembedded.dev * r3123b4d1cf 10openembedded.git/recipes/tasks/task-qt4-x11.bb: |
05:11.02 | CIA-47 | task-qt4-x11: Move libqtxmlpatterns4 to RRECOMMENDS |
05:11.02 | CIA-47 | Fixes qt4 4.6.x images. |
05:11.02 | CIA-47 | Signed-off-by: Tom Rini <tom_rini@mentor.com> |
05:11.03 | CIA-47 | 03Tom Rini <tom_rini@mentor.com> 07org.openembedded.dev * r295db8cb3f 10openembedded.git/recipes/ (images/qt4e-base-image.bb tasks/task-qt4e.bb): |
05:11.04 | CIA-47 | qt4e-demo-image: Switch to using task-qt4e.bb |
05:11.04 | CIA-47 | In task-qt4e.bb put the xmlpatterns bits in RRECOMMENDS for QT 4.6.x |
05:11.04 | CIA-47 | Signed-off-by: Tom Rini <tom_rini@mentor.com> |
05:11.04 | *** join/#oe mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net) |
05:16.14 | *** join/#oe polyonymous_ (~hacker@g230197231.adsl.alicedsl.de) |
05:20.30 | *** join/#oe mrc3 (~ddiaz@189.157.120.195) |
05:25.26 | *** join/#oe wicknix (~matt@74.213.216.232) |
05:42.55 | *** join/#oe mrc3 (~ddiaz@189.157.113.36) |
05:59.31 | *** join/#oe mrc3 (~ddiaz@189.157.112.157) |
06:19.59 | *** join/#oe mrc3 (~ddiaz@189.157.110.208) |
06:23.47 | *** join/#oe Russ (foobar@ip70-176-251-1.ph.ph.cox.net) |
06:24.50 | *** part/#oe Russ (foobar@ip70-176-251-1.ph.ph.cox.net) |
06:24.58 | *** join/#oe amarsman_nl (~marsman@89.184.175.76) |
06:25.53 | *** join/#oe amarsman_nl (~marsman@89.184.175.76) |
06:27.08 | *** join/#oe anr78 (~Mich@147.84-49-231.nextgentel.com) |
06:44.46 | *** join/#oe hwtechnik (~hwtechnik@h081217109005.dyn.cm.kabsi.at) |
06:56.43 | *** join/#oe CMoH-notebook (~cipi@95.76.68.223) |
06:56.43 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
06:58.24 | *** join/#oe dth (~dth@a89-183-153-144.net-htp.de) |
07:11.21 | *** join/#oe rob_w (~bob@ppp-93-104-172-83.dynamic.mnet-online.de) |
07:14.02 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
07:28.58 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
07:31.33 | eFfeM_work | Jay7: was afk yesterday evening, thanks for fixing the oestats thingie |
07:31.44 | eFfeM_work | & gm everyone |
07:34.47 | *** part/#oe mrj101 (~mrj10@63.252.64.254) |
07:35.15 | mckoan | good morning |
07:36.59 | *** part/#oe dth (~dth@a89-183-153-144.net-htp.de) |
07:41.28 | *** join/#oe moi2134 (~moi@cpe-66-27-113-207.san.res.rr.com) |
07:41.50 | *** join/#oe mrc3 (~ddiaz@189.157.113.122) |
07:44.50 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * ree63bd5d2e 10openembedded.git/recipes/tasks/task-base.bb: |
07:44.50 | CIA-47 | task-base: bump PR to pick changes from nokia900.conf |
07:44.50 | CIA-47 | * lack of coffee made me thing that MACHINE_KERNEL_PR bump in |
07:44.50 | CIA-47 | 648bd1c785fae9de66001dc588720366b9ebda2c is what I need, sorry for |
07:44.50 | CIA-47 | that |
07:44.50 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
07:53.09 | *** join/#oe sgw (~sgw@nat/intel/x-lqudazrlgtdnigyn) |
07:56.40 | *** join/#oe rob_w (~bob@217.237.177.190) |
07:57.09 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
07:59.56 | *** join/#oe mrc3 (~ddiaz@189.157.108.248) |
08:06.06 | *** join/#oe rschus (~rschus@167.163.71-86.rev.gaoland.net) |
08:15.19 | *** join/#oe dth (~dth@a89-183-153-144.net-htp.de) |
08:21.09 | *** join/#oe dth (~dth@a89-183-153-144.net-htp.de) |
08:21.15 | *** join/#oe wicknix (~matt@43.173-254-132.cellcom.com) |
08:23.02 | *** join/#oe mr_nice|work (~mr_nice|w@83-64-51-210.static.xdsl-line.inode.at) |
08:24.17 | *** part/#oe dth_ntb (~dth@a89-183-153-144.net-htp.de) |
08:29.03 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
08:31.19 | *** join/#oe Philippe (~Philippe@a83-245-252-47.elisa-laajakaista.fi) |
08:37.52 | *** join/#oe esbenh (~esben@77.233.226.4) |
08:42.54 | XorA|gone | morning |
08:44.53 | *** join/#oe Guest64317 (~methril@189.27.129.118.dynamic.adsl.gvt.net.br) |
08:52.25 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
08:55.48 | *** join/#oe RP__ (~richard@dan.rpsys.net) |
08:59.00 | Jay7 | morning |
08:59.21 | Jay7 | sh#t :( my buildhost hangs this night |
08:59.50 | ka6sox | bummers |
09:01.39 | *** join/#oe stefan_schmidt (~stefan@2001:638:602:1183:21f:16ff:fe0d:7d41) |
09:03.04 | *** join/#oe aloril (~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) |
09:03.24 | ant_work | Jay7: until yesterday the lenght of failure logs on tinderox could not exceed 24kb. Is it wanted limit? see http://tinderbox.openembedded.net/public/logs/task/25563737.txt |
09:04.13 | Jay7 | ant_work: no, but I didn't changed anything about this.. |
09:04.37 | Jay7 | ka6sox: haven't you limit on POST size anywhere? |
09:05.10 | ka6sox | size? not seen one... |
09:05.14 | Jay7 | ok |
09:05.33 | ka6sox | but large number of small POSTS are difficult on server |
09:05.39 | ka6sox | much better to batch results |
09:05.41 | Jay7 | yes, I know.. |
09:05.55 | ka6sox | but lets say for only 1 recipe in a build |
09:05.57 | ka6sox | then send |
09:06.27 | Jay7 | it's a bit hard to catch |
09:06.39 | Jay7 | easier to put all data after build |
09:06.53 | ka6sox | for entire distro that would be hard |
09:07.01 | ka6sox | can you separate by package? |
09:07.06 | ka6sox | then send by package? |
09:07.09 | Jay7 | well.. may be you are right |
09:07.34 | Jay7 | there is no 'package processed' event in bitbake as far I know |
09:07.37 | ka6sox | I would rather not see 5MB of data all @ 1 time |
09:07.40 | Jay7 | task and build |
09:08.18 | ka6sox | no milestones of packages built..even so they are staged? |
09:09.04 | Jay7 | it should be possible to catch by latest package task |
09:09.43 | Jay7 | do_package iirc |
09:09.47 | ka6sox | I would think that monitoring the log output you would catch start of package build task. |
09:09.49 | ka6sox | right |
09:10.06 | ka6sox | do_package does have some debuggging output I've seen. |
09:10.10 | Jay7 | but there is do_rootfs for images |
09:10.11 | XorA|gone | hey ka6sox are you on oe-devel? |
09:10.13 | *** join/#oe florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
09:10.13 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
09:10.22 | ka6sox | XorA|gone, yep |
09:10.41 | XorA|gone | ka6sox: you never commented on my emails about wiki.openembedded.net being broken for captcha |
09:10.45 | Jay7 | ka6sox: we should ask kergoth or RP about best way |
09:10.49 | XorA|gone | ka6sox: its very confusing |
09:11.06 | ka6sox | XorA|gone, I did...here but you missed them... |
09:11.19 | ka6sox | you shouldn't have been on the list you were on |
09:11.23 | ka6sox | that is fixed |
09:11.29 | ka6sox | last thursday your time. |
09:11.34 | XorA|gone | ka6sox: ah, right, cool, yeah Ive been on hols and in Japan working at moment |
09:11.44 | ka6sox | ah... |
09:12.03 | ka6sox | I was driving to San Francisco fixing it. |
09:12.13 | XorA|gone | ka6sox: dont drive and code :-D |
09:12.31 | ka6sox | no, I asked the DBA and wikimaster to fix it :D |
09:12.43 | XorA|gone | hehe |
09:12.45 | XorA|gone | best way |
09:12.54 | ka6sox | ya, thats their baby... |
09:13.06 | ka6sox | now to add varnish and make it run real smooth |
09:13.15 | XorA|gone | not teflon? |
09:13.47 | ka6sox | there are like 10 ways to do it...we started with varnish and it works. |
09:14.05 | XorA|gone | just coat your shoulders in teflon then |
09:14.14 | ka6sox | I have 21 mediawiki with varnish |
09:14.24 | ka6sox | 15 on one server |
09:15.17 | ka6sox | if it really becomes a problem I'll do something about caching the php |
09:15.17 | Jay7 | like typo3 because you may have one codebase for all sites |
09:15.47 | mckoan | qt4-embedded_4.7.1.bb do_configure failed |
09:15.57 | ka6sox | Jay7, the 15 mediawiki is 1 codebase symlinked |
09:16.07 | mckoan | why my qt4-embedded_4.7.1 build requires mysql5_5.1.40 ? |
09:16.10 | Jay7 | ka6sox: that's right :) |
09:17.59 | XorA|gone | has much more fun with Alfresco than mediawiki :-D |
09:18.49 | *** join/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl) |
09:18.59 | Jay7 | prefers dokuwiki for small-sized wikis |
09:19.19 | Jay7 | OE's one is small-sized :) |
09:21.07 | ka6sox | there are a lot of good projects out there. |
09:34.23 | *** join/#oe CMoH (~cipi@95.76.68.223) |
09:34.23 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
10:07.00 | *** join/#oe hrw (~hrw@linaro/hrw) |
10:08.03 | *** join/#oe mlip (~mlip@unaffiliated/mlip) |
10:10.42 | *** join/#oe sgw (~sgw@116.246.20.131) |
10:11.20 | *** join/#oe RP__ (~richard@93-97-173-237.zone5.bethere.co.uk) |
10:21.07 | pb_ | stabs microchip |
10:21.10 | pb_ | poxy pic icsp interface |
10:24.13 | otavio | How is gcc tests going? |
10:25.25 | Jay7 | slowly.. |
10:25.39 | Jay7 | otavio: khem reverted his patch from master |
10:25.51 | Jay7 | my buildhost hangs tonight |
10:26.03 | otavio | Right. My build still fails using minimal |
10:26.04 | otavio | :-( |
10:26.20 | Jay7 | so I'm restarting now only ben-nanonote builds |
10:26.56 | Jay7 | angstrom-2010.x/collie was successfull |
10:28.28 | ka6sox | pb_, I stopped using it years ago....wierdest risc thing I've ever used |
10:32.18 | pb_ | yeah, the instruction set is a bit funky. I prefer AVR normally but in this case the comparable atmel parts were way more expensive. |
10:32.47 | pb_ | pic12f1822 is actually quite a cool chip, you get hardware uart, hardware i2c/spi, temperature sensor, capsense and a bunch of other stuff for about $0.50. |
10:33.01 | pb_ | only problem is that I can't erase the flash :-} |
10:33.51 | ant_work | pb_: gamma rays ? neutron beam? vodoo? |
10:33.55 | ka6sox | doesn't help. all the stuff I used to programme on is "legacy" |
10:34.22 | ka6sox | ant_work, neutrinos |
10:34.40 | ant_work | oh, Higg's boson, yes |
10:35.23 | ka6sox | we had to glue tantalum meta top and bottom of RAM chips because we couldn't afford space grade RAM. |
10:35.30 | *** join/#oe vitus_ (~vitus@145.253.169.210) |
10:35.36 | ka6sox | s/meta/metal. |
10:35.49 | ka6sox | and 12bits to get 8 good ones. |
10:39.08 | ka6sox | pb_, that is a lot of value for a small price. |
10:39.13 | ka6sox | good luck |
10:41.12 | *** join/#oe mlip (~mlip@unaffiliated/mlip) |
10:43.35 | otavio | eFfeM_work: Hello |
10:44.10 | otavio | eFfeM_work: I received your reply about the pull request. |
10:48.38 | *** join/#oe GNUtoo|laptop (~gnutoo@95.232.143.186) |
10:55.34 | *** join/#oe B_Lizzard (~havoc@athedsl-432203.home.otenet.gr) |
10:57.08 | Philippe | Nothing like a good OE build to warm up the place :D |
10:59.56 | otavio | Philippe: lol |
11:01.54 | Philippe | oc |
11:02.09 | Philippe | it is -28 outside here, so all little bits help |
11:03.27 | mckoan | Philippe: -28 ! where are you? |
11:05.13 | eFfeM_work | otavio: ok; for reviewing git pull is not that convenient (or I am too git n00bish) |
11:05.22 | Philippe | mckoan, Finland |
11:05.39 | otavio | eFfeM_work: no problem. I can set my SMTP to send the mails |
11:05.54 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
11:05.57 | otavio | eFfeM_work: but did you checked the changes? |
11:06.25 | eFfeM_work | nope, saw your mail, but can't easily access the git stuff (or don't know how to do so easily) |
11:06.30 | otavio | eFfeM_work: about cups 1.4.6 I can do really soon, just after merging it. |
11:06.39 | eFfeM_work | otavio: great |
11:06.57 | otavio | eFfeM_work: did you get the link? |
11:07.04 | eFfeM_work | for git, yes |
11:07.13 | otavio | eFfeM_work: I am with problems to push from here ... |
11:07.25 | otavio | eFfeM_work: so if you can merge what seems OK for you, it would be nice. |
11:07.28 | eFfeM_work | is git send-email an option for you ? |
11:07.36 | otavio | eFfeM_work: it can be |
11:07.43 | otavio | eFfeM_work: I need to setup it only |
11:08.13 | eFfeM_work | can't do too much form work anyway (and tonight I am performing a social duty I agreed on two years ago ;-) ) |
11:09.46 | otavio | eFfeM_work: ahah OK :-) |
11:09.51 | otavio | eFfeM_work: so it is a no-go for today |
11:09.55 | otavio | eFfeM_work: no problem |
11:13.10 | eFfeM_work | probably; if the changes are mailed anyone can pick it up (and I can review and ack from here; that is something I typically do while a build is running) |
11:15.12 | otavio | eFfeM_work: OK |
11:15.15 | otavio | eFfeM_work: will send them |
11:19.25 | otavio | eFfeM_work: sending them all |
11:34.23 | *** join/#oe rob_w (~bob@217.237.177.190) |
11:55.15 | *** join/#oe tuc (c2b12d3c@gateway/web/freenode/ip.194.177.45.60) |
12:09.20 | CIA-47 | 03Mario Schuknecht <m.schuknecht@dresearch.de> 07org.openembedded.dev * r37832a3474 10openembedded.git/recipes/linux/ (linux-2.6.24/hipox/hipox-phy.patch linux_2.6.24.bb): |
12:09.20 | CIA-47 | linux-2.6.24: phy handling fixed for hipox machine |
12:09.20 | CIA-47 | * phy switching enabled |
12:09.20 | CIA-47 | * link status handling fixed |
12:09.20 | CIA-47 | Signed-off-by: Mario Schuknecht <m.schuknecht@dresearch.de> |
12:09.20 | CIA-47 | Acked-by: Steffen Sledz <sledz@dresearch.de> |
12:20.09 | *** join/#oe Gaston|Home (~Gaston@ua-83-227-239-139.cust.bredbandsbolaget.se) |
12:28.41 | *** join/#oe hrw (~hrw@linaro/hrw) |
12:52.44 | *** join/#oe ajb_oe (~user@cbnluk-gw0.cambridgebroadband.com) |
12:57.32 | *** join/#oe likewise (~likewise@196-79-ftth.onsneteindhoven.nl) |
12:59.24 | *** join/#oe likewise_ (~likewise@42-81-ftth.onsneteindhoven.nl) |
13:01.57 | ajb_oe | I'm having trouble adding libnet-dev to my SDK, it comes up with "satisfy_dependencies_for: Cannot satisfy the following dependencies... libnet *", is there any way I can see what is the dependancy it's worried about. |
13:13.36 | *** join/#oe CMoH (~cipi@95.76.68.223) |
13:13.36 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
13:16.18 | *** join/#oe CMoH (~cipi@95.76.68.223) |
13:16.18 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
13:19.25 | *** join/#oe RCFout (~rcf@136.174-243-81.adsl-dyn.isp.belgacom.be) |
13:21.44 | mckoan | ERROR: QA Issue with libgettextlib: package libgettextlib contains bad RPATH...gettext_0.18.bb |
13:21.50 | mckoan | any clue? |
13:27.38 | *** join/#oe aloisiojr (~aloisio@187.113.112.68) |
13:32.10 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
13:37.39 | *** join/#oe mwester (~mwester@nslu2-linux/mwester) |
13:38.52 | *** join/#oe vitus_ (~vitus@145.253.169.210) |
13:49.54 | *** join/#oe rob_w (~bob@ppp-93-104-172-83.dynamic.mnet-online.de) |
13:50.19 | *** join/#oe kergoth (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
13:54.03 | *** join/#oe kevinsc (~a0214685@nat/ti/x-dilenutccfhboley) |
13:56.44 | *** join/#oe vitus_ (~vitus@145.253.169.210) |
14:05.21 | *** join/#oe sgw (~sgw@116.246.20.131) |
14:27.10 | *** join/#oe amarsman_nl (~marsman@89.184.175.76) |
14:30.32 | martinmeba | mckoan: i have the exact problem |
14:35.26 | mckoan | martinmeba: I'm rebuilding but I guess it will be the same |
14:35.31 | martinmeba | yeah |
14:35.38 | martinmeba | i think it started in the last few days |
14:35.57 | JaMa | because QA check was enabled and later fixed.. |
14:35.59 | mckoan | martinmeba: yes, sure. I wonder who introduced such error |
14:36.58 | JaMa | see [PATCH] insane.bbclass: fix the check for bad RPATH |
14:38.48 | Tartarus | Yes |
14:38.54 | Tartarus | So we need to fix the RPATH issue, if possible |
14:40.34 | martinmeba | so patch/456 ? |
14:40.35 | Tartarus | poky may be of use here |
14:41.03 | Tartarus | No, that patch made the RPATH erors be fatal |
14:41.12 | Tartarus | JaMa posted a patch i thought to make it not fatal, for now |
14:41.19 | Tartarus | But I mean we should fix the actual QA error that shows |
14:41.21 | *** join/#oe soltys (soltys@83.168.118.74) |
14:42.31 | Tartarus | ie for the db one, maybe we just update to 5.1.19 like poky did, since it's backwards compat |
14:42.39 | Tartarus | and apparently doesn't have the problem |
14:43.59 | JaMa | martinmeba: 573 makes it not fatal, but as Tartarus said use it only if you need to build it quick, otherwise better to fix the issue |
14:44.10 | martinmeba | yeah |
14:44.17 | martinmeba | i think i need to build it quick |
14:44.33 | martinmeba | i need to let a unit soak in a thermal chamber and everything just broke |
14:44.40 | *** join/#oe hwtechnik (~hwtechnik@h081217109005.dyn.cm.kabsi.at) |
14:45.28 | mckoan | what about reverting the patch that cause it? |
14:45.48 | martinmeba | mckoan: yes - that is probably best |
14:46.42 | CIA-47 | 03Otavio Salvador <otavio@ossystems.com.br> 07master * r48ee8fa099 10openembedded.git/recipes/cdparanoia/cdparanoia_svn.bb: |
14:46.42 | CIA-47 | cdparanoia (svn): use build variables to fix packaging when using empty prefix |
14:46.42 | CIA-47 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
14:46.42 | CIA-47 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
14:47.41 | mckoan | definitely would be, at least until the whole implication is solved |
14:48.42 | JaMa | mckoan: that's actually worst solution |
14:48.50 | Tartarus | Well, yeah, what jaMa said |
14:48.53 | Tartarus | We have problems |
14:48.56 | JaMa | mckoan: that error will still be there |
14:48.58 | Tartarus | We shouldn't mask them |
14:49.03 | Tartarus | We have time to fix them |
14:49.06 | Tartarus | Lets fix them |
14:49.17 | Tartarus | And look at poky when needed since they've had that check for a while |
14:49.26 | JaMa | mckoan: best _temporary_ solution is _show_ it, but not fatal (like 573 does) |
14:49.38 | mckoan | I haven't the foggiest idea about how to solve it |
14:49.42 | JaMa | mckoan: hidding that problem from log won't help anyone and nobody will fix it |
14:49.57 | JaMa | mckoan: than pw-am.sh 573 is for you |
14:50.26 | martinmeba | I guess I will have to raise my hand and say I don't know where to start |
14:51.29 | Tartarus | khem fixed this in binutils the th patch is noisy, heh |
14:51.47 | mckoan | martinmeba: let's do this tricky stuff |
14:51.48 | JaMa | he fixed it also in python-sqlite |
14:51.55 | mckoan | martinmeba: contrib/patchwork/pw-am.sh 573 |
14:52.10 | Tartarus | http://pastebin.com/wy4sepAe |
14:53.08 | martinmeba | mckoan: thanks |
14:55.17 | *** join/#oe demigod2k (4b3aceb1@gateway/web/freenode/ip.75.58.206.177) |
14:56.19 | demigod2k | my lousy external compiler was choking on a file in gnutls (easy to workaround) and now libtiff. was there any well known issue with earlier gcc's failing to do sysroot properly, especially around libtool? |
14:56.28 | *** join/#oe mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net) |
14:57.24 | demigod2k | google hit on several things. I just don't understand how I'm passing --sysroot= on almost every line, but it's still looking in the default sysroot instead of the OE staging dir |
15:14.55 | *** join/#oe ensc_ (~irc-ensc@p5DF2C098.dip.t-dialin.net) |
15:15.51 | *** join/#oe hrw (~hrw@linaro/hrw) |
15:16.36 | martinmeba | so with patch 573, I also get QA errors in gnutils, tiff, acl |
15:20.14 | *** join/#oe hrww (~hrw@linaro/hrw) |
15:21.33 | martinmeba | also neon, gnome-vfs-plugin, schroedinger, libcdio++, libiso9660++ |
15:22.25 | JaMa|Off | martinmeba: but your build continues, right? |
15:22.29 | martinmeba | yes |
15:27.03 | *** join/#oe pespin (~pespin@171.pool85-50-76.dynamic.orange.es) |
15:31.41 | otavio | eFfeM_work: you pushed only one of the patches? |
15:35.37 | mckoan | martinmeba: what about to roll-back to a stable version? -2 days |
15:38.01 | mckoan | alway take note about working versions (his own tagging method) http://www.kaeilos.com/latest-changes |
15:38.13 | mckoan | git reset --hard 6a97f8c4f99330848b8dbe7e54b3560eceb486c8 |
15:38.49 | mckoan | martinmeba: if you are in a hurry |
15:39.20 | martinmeba | mckoan: thanks |
15:40.40 | JaMa|Off | mckoan: did you read what I said :/ |
15:42.38 | mckoan | JaMa|Off: about hiding/ignoring the problem? yes |
15:44.57 | JaMa|Off | then in what aspect is " stable version? -2 days" better than current head + 573? |
15:46.06 | mckoan | JaMa|Off: I don't know, I read martinmeba comment about further problems, sorry :-) |
15:46.55 | mckoan | I perfectly understand his feelings, some time happens that you have no time to dig in the code |
15:48.16 | mckoan | after his sudden crisis, he/we could go ahead solving the problem ;-) |
15:50.16 | eFfeM_work | otavio: I pushed cdparanoia; I felt quite comfortable with that one and as I am listed as maintainer for that version I felt quite comfortable pushing it |
15:50.31 | *** join/#oe xeon-enouf (~xeon-enou@unaffiliated/xeon-enouf) |
15:51.24 | *** join/#oe JaMa|Off (~martin@161-24.13.24.78.awnet.cz) |
15:52.34 | eFfeM_work | otavio: wrt e.g. sdk.bbclass: our policy requires two acks for it (and frankly atm I cannot really review it); cmake probably too, and for some of the other things these are recipes where I have no knowledge about; I've added acks for the ones I feel they are ok (and if there is a 2nd ack I'm happy to push them). |
15:54.18 | eFfeM_work | need to leave now, later.... |
15:57.16 | *** join/#oe mrc3 (~ddiaz@189.157.113.39) |
16:11.27 | *** join/#oe khem (~khem@99-57-141-118.lightspeed.sntcca.sbcglobal.net) |
16:12.01 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
16:14.37 | ajb_oe | well as far as I can tell the problem isn't libpcap which is the only dependancy libnet lists in the .bb file |
16:15.18 | *** join/#oe mario-go` (~user@67.205.85.241) |
16:15.46 | ajb_oe | is I bitbake libnet on it's own every thing is fine, so why can't I add it to the SDK? |
16:20.05 | *** join/#oe mario-goulart (~user@67.205.85.241) |
16:31.39 | *** join/#oe nitink (~nitink@nat/intel/x-rmjcsdhpwfdorbck) |
16:32.09 | *** join/#oe Jefro (~josiermi@134.134.139.75) |
16:32.58 | *** join/#oe kevinsc1 (~a0214685@nat/ti/x-rphgxquaaryjoqmy) |
16:41.47 | Jay7 | otavio, khem: my builds of angstrom-2010 and minimal for ben-nanonote (mipsel) was fine |
16:43.13 | *** join/#oe moi2134 (~moi@cpe-66-27-113-207.san.res.rr.com) |
16:45.10 | otavio | Jay7: even sdk? |
16:45.16 | otavio | khem: mine keeps failing |
16:45.44 | Jay7 | otavio: no, console-image, x11-image, opie-image |
16:46.01 | Jay7 | otavio: did you mean native-sdk-image? |
16:46.12 | otavio | meta-toolchain |
16:46.16 | Jay7 | ah |
16:46.26 | Jay7 | well.. I can test it later |
16:48.20 | Jay7 | otavio: started |
16:50.04 | *** join/#oe likewise (~likewise@82-170-243-215.ip.telfort.nl) |
16:53.42 | otavio | Jay7: nice |
16:53.54 | otavio | Jay7: so we will know if it fails just for me or for you too |
16:54.08 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
16:56.25 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r28637f3e90 10openembedded.git/recipes/openmoko-3rdparty/ (openmoko-gps_0.0.1+svnr9.bb openmoko-gps_svn.bb): |
16:56.26 | CIA-47 | openmoko-gps: bump SRCREV, fix QA issues, fix hardcoded path, use bindir/datadir and rename recipe |
16:56.26 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
16:56.27 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r97240c982e 10openembedded.git/recipes/mokoeightball/ (files/fixpath.patch mokoeightball_svn.bb): |
16:56.27 | CIA-47 | mokoeightball: fix hardcoded paths and QA issues |
16:56.27 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
16:58.07 | GNUtoo|laptop | hi JaMa|Off |
16:58.10 | GNUtoo|laptop | ah you're off |
16:58.19 | GNUtoo|laptop | JaMa|Off, ping me when you're not off anymore |
16:58.26 | JaMa|Off | GNUtoo|laptop: just arrived |
16:58.35 | *** join/#oe amarsman_nl (~marsman@89.184.175.76) |
16:58.47 | GNUtoo|laptop | JaMa, ok, what should we do to reguards to -ggdb in SHR |
16:58.52 | GNUtoo|laptop | I want to be able to debug FSO |
16:59.04 | GNUtoo|laptop | so we need some compilation flags for debuggings |
16:59.24 | Tartarus | How bug debugging? |
16:59.29 | JaMa | what's wrong with -dbg packages? |
16:59.33 | Tartarus | Stepping into libc too or no? |
16:59.44 | Tartarus | JaMa, without -ggdb -dbg packages aren't helpful really |
17:00.28 | fray | don't need -ggdb, -g is sufficient, unless the compiler defaults are strange |
17:00.36 | Tartarus | Well, ok, also true |
17:00.39 | Tartarus | But we don't do -g |
17:00.44 | Tartarus | (A change from poky) |
17:01.01 | GNUtoo|laptop | JaMa, they don't have debugging symbols: |
17:01.09 | fray | (advantage of -g over -ggdb is that if the debug format changes in the system you don't have to go and update it everywhere) |
17:01.37 | fray | anything lacking debug symbols should be caught and a warning issued IMHO.. -dbg packages are incredibly important for any device that goes into the field |
17:01.43 | JaMa | Tartarus: ah I thought that sane-toolchain-eglibc.inc had -ggdb |
17:01.51 | Tartarus | JaMa, nope |
17:01.54 | Tartarus | angstrom does |
17:02.00 | JaMa | yup reading it now |
17:02.00 | Tartarus | and I swear we used to default to it |
17:02.03 | Tartarus | is got log'ing |
17:02.08 | fray | (recently in Poky I put in an enhancement that added corresponding sources to the -dbg packages.. so you can do debugging on the device or remotely without having your original build tree) |
17:02.24 | Tartarus | nope, I'm crazy |
17:02.30 | GNUtoo|laptop | JaMa, http://www.pastie.org/1567574 |
17:02.45 | Tartarus | On non-debug builds we default to just -O2 |
17:02.51 | Tartarus | debug builds get -g |
17:03.00 | Tartarus | (and there's minor games being played against *glibc) |
17:03.05 | fray | Tartarus I remember way back when (before OE) -ggdb and such were used in our builds |
17:03.31 | fray | ...way back when... roughly 1998 or so.. ;) |
17:03.52 | Tartarus | heh |
17:04.07 | JaMa | 543f79f0298ff23b03339172e8a2f3f05784495e should still default to -g, no? |
17:04.08 | fray | (hard to believe it's been that long since the PPC Reference releases) |
17:04.33 | Tartarus | JaMa, BUILD_OPTIMIZATION is host run stuff |
17:04.52 | GNUtoo|laptop | indeed on target no -g |
17:04.55 | GNUtoo|laptop | that is to say: |
17:05.05 | GNUtoo|laptop | http://pastebin.com/D7ddkJjM |
17:05.06 | Tartarus | Which also means we have some silliness in sane-toolchain* |
17:05.10 | GNUtoo|laptop | do you see some -g |
17:05.45 | Tartarus | GNUtoo|laptop, as a local fix, add BUILD_OPTIMIZATION += "-g" (or some other -g variant) |
17:05.50 | Tartarus | er |
17:05.51 | Tartarus | FULL |
17:06.01 | Tartarus | and FULL_OPT_pn-glibc += "-g" too |
17:06.05 | Tartarus | if you want to step into libc stuff |
17:06.34 | GNUtoo|laptop | yes but could we add that to SHR? |
17:07.07 | Tartarus | Yes, JaMa may want to look at angstrom bits again and maybe we update sane-toolchain* to be a little less silly (and also drop -g from host run tools?) |
17:07.30 | Tartarus | goes back to not procrastinating on something else |
17:07.31 | JaMa | agree that it should be fixed in sane-toolchain |
17:08.14 | JaMa | won't look into it today, need to pack stuff for skiing and leaving in 4 am so want to go to bed early today |
17:08.42 | GNUtoo|laptop | JaMa, will you look into it at some point? |
17:09.34 | Tartarus | GNUtoo|laptop, you could try too :) angstrom-* gets it right except I think for debug symbols to *glibc (see what I said above for fix), of course khem points out that w/ -fomit-frame-pointers debugging is always sub-optimal |
17:09.41 | Tartarus | really, hiding irc now |
17:10.22 | GNUtoo|laptop | ok thanks |
17:10.23 | mwester | Procrastination is a valuable time-management technique, though. :) |
17:11.50 | *** join/#oe unsolo (~unsolo@50.80-203-43.nextgentel.com) |
17:12.28 | martinmeba | I am having issues with the 2008.1 os branch using glibc |
17:18.10 | *** join/#oe Philippe (Philippe@2002:559c:53ce::559c:53ce) |
17:21.31 | *** join/#oe kristoffer (~kristoffe@c-f3dbe555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
17:28.41 | *** join/#oe awozniak (~awozniak@adsl-76-205-222-174.dsl.snlo01.sbcglobal.net) |
17:28.59 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
17:33.29 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
17:34.26 | *** join/#oe toi (~peter@d54C2AA76.access.telenet.be) |
17:37.38 | *** join/#oe Heinervdm (~thomas@pD9E14A94.dip.t-dialin.net) |
17:38.39 | khem | martinmeba: you have to describe the problem |
17:38.59 | khem | we have not (yet) developed mind reading skills |
17:42.02 | *** join/#oe kevinsc (~a0214685@nat/ti/x-mvjkaignpcuoivkb) |
17:44.11 | Tartarus | OK, what the heck |
17:44.39 | Tartarus | do_package_qa should show up in *.dot right? |
17:44.49 | Tartarus | (when INHERIT += "insane" of course) |
17:48.23 | *** join/#oe risca (~risca@tappan-125-95.eduroam.liu.se) |
18:01.15 | *** join/#oe anarsoul (~anarsoul@46.28.101.209) |
18:02.53 | *** join/#oe Willie (~william@69.149.106.94) |
18:19.08 | *** join/#oe morphis (~morphis@dslb-088-070-138-205.pools.arcor-ip.net) |
18:22.39 | GNUtoo|laptop | hmmm boost has issues |
18:22.59 | GNUtoo|laptop | ERROR: QA Issue with boost: package boost contains bad RPATH /home/gnutoo/embedded/oe/oetmps/htcdream/sysroots/armv6-novfp-oe-linux-gnueabi/bin in file /home/gnutoo/embedded/oe/oetmps/htcdream/work/armv6-novfp-oe-linux-gnueabi/boost-1.45.0-r9.2/packages-split/boost/usr/lib/libboost_wave.so.1.45.0 |
18:23.05 | GNUtoo|laptop | is it a bad compiler flag? |
18:25.01 | Tartarus | basically, yes |
18:25.53 | GNUtoo|laptop | so what would be the fix? |
18:26.40 | Tartarus | So, if I follow things right, stop passing -rpath manually |
18:26.49 | GNUtoo|laptop | ok |
18:26.50 | Tartarus | doesn't have a good example handy |
18:27.00 | GNUtoo|laptop | I'll grep for rpath |
18:29.32 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r25eaf1dd9a 10openembedded.git/recipes/gnome/libsoup-2.4_2.33.6.bb: |
18:29.32 | CIA-47 | libsoup-2.4: add 2.33.6 version needed for newer webkit-efl |
18:29.32 | CIA-47 | Acked-by: Khem Raj <raj.khem@gmail.com> |
18:29.32 | CIA-47 | Acked-by: Klaus Kurzmann <mok@fluxnetz.de> |
18:29.32 | CIA-47 | Tested-by: Klaus Kurzmann <mok@fluxnetz.de> |
18:29.33 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
18:29.44 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r8e80816f04 10openembedded.git/recipes/glib-2.0/ (7 files in 2 dirs): |
18:29.44 | CIA-47 | glib-2.0: add 2.28.0, needed by newer libsoup |
18:29.44 | CIA-47 | Acked-by: Khem Raj <raj.khem@gmail.com> |
18:29.44 | CIA-47 | Acked-by: Klaus Kurzmann <mok@fluxnetz.de> |
18:29.45 | CIA-47 | Tested-by: Klaus Kurzmann <mok@fluxnetz.de> |
18:29.45 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
18:29.46 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * rf202b0d8a4 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: |
18:29.46 | CIA-47 | SHR: drop P_V for glib-2.0 (upgrades from 2.26.1 to 2.28.0) |
18:29.47 | CIA-47 | Acked-by: Khem Raj <raj.khem@gmail.com> |
18:29.47 | CIA-47 | Acked-by: Klaus Kurzmann <mok@fluxnetz.de> |
18:29.48 | CIA-47 | Tested-by: Klaus Kurzmann <mok@fluxnetz.de> |
18:29.48 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
18:32.34 | martinmeba | khem: I was refering to the earlier part of the discussion about the RPATH issues |
18:33.48 | *** join/#oe zenlinux_laptop (~sgarman@masterfoo.zenlinux.com) |
18:35.53 | *** join/#oe mr_nice (~nice@95-90-73-27-dynip.superkabel.de) |
18:42.19 | pespin | hi, I'm having problems building a kernel for which I've just written the recipe: http://paste.pocoo.org/show/339796/ |
18:43.23 | pespin | something weird's happening, (apart from error) because there's trying to build headers for 2.6.32 headers and kernel is actually 2.6.37 |
18:45.38 | *** join/#oe kristoffer (~kristoffe@c-f3dbe555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
18:46.16 | GNUtoo|laptop | some recipe like glibc unset LDFLAGS |
18:46.18 | GNUtoo|laptop | I'll try that |
18:46.26 | GNUtoo|laptop | but I bet I would have GNU Hash issue |
18:46.33 | GNUtoo|laptop | but I could workarround |
18:48.33 | martinmeba | pespin: if you look in openembedded/conf/distro/angstrom-<version you are using>, you will see a note about the kernel vs. header version |
18:50.41 | pespin | martinmeba, ok thanks, so that's not a problem then |
18:50.59 | martinmeba | yeah - probably not |
18:51.04 | pespin | ay idea on why are the errors appearing though? |
18:51.12 | martinmeba | i'd have to see your kernel recipe |
18:51.13 | martinmeba | no idea |
18:52.47 | pespin | martinmeba, http://paste.pocoo.org/show/339779/ |
18:55.12 | pespin | btw, this is the actual log file -> http://paste.pocoo.org/show/339803/ |
18:56.19 | kergoth | meh |
18:57.38 | martinmeba | pespin: this doesn't look like an issue with your kernel |
18:58.05 | martinmeba | it is blowing up before that |
18:58.18 | pespin | martinmeba, machine config maybe? I've done it some minutes ago too |
18:58.51 | martinmeba | i am not sure - I have to run. good luck |
18:59.15 | pespin | ok, thanks anyway :) |
18:59.25 | pespin | If someone wants to have a look at machine config -> http://paste.pocoo.org/show/339805/ |
18:59.41 | blindvt | khem, mind bumping uClibc rev to 0f4516e32c3a2186e6b6f074cfc6a57bde90e9cc ? |
19:00.01 | *** join/#oe moi2134 (~moi@cpe-66-27-113-207.san.res.rr.com) |
19:00.26 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * rde373354c2 10openembedded.git/recipes/tasks/task-shr-feed.bb: |
19:00.26 | CIA-47 | task-shr-feed: add bison and automake |
19:00.26 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
19:00.44 | blindvt | khem, i'd like to call it final but if you could give it a whirl it would be great -- TIA |
19:01.16 | *** join/#oe NightMonkey (debian-tor@pdpc/supporter/professional/nightmonkey) |
19:02.56 | GNUtoo|laptop | disabling LDFLAGS didn't fix the RPATH issue |
19:04.08 | *** join/#oe amarsman_nl (~marsman@89.184.175.76) |
19:06.54 | khem | blindvt: well with thumb broken uclibc bump is not going to happen in OE |
19:07.10 | Tartarus | khem, um, hey |
19:07.22 | Tartarus | Is insane.bbclass fully working (ie hitting RPATH errors) for you? |
19:07.23 | khem | blindvt: most of armv5 and below use thumb by default |
19:07.39 | khem | Tartarus: all I build it native-sdk-image |
19:07.47 | khem | and it works with stringent checks |
19:07.56 | blindvt | darn thumb1 |
19:08.00 | Tartarus | are you sure? |
19:08.13 | Tartarus | minimal isn't able to his RPATH errors for me |
19:08.17 | Tartarus | try building db in your setup |
19:08.18 | khem | blindvt: I could not find moments to fix it myself yet |
19:08.31 | khem | blindvt: hopefully its fixable |
19:08.51 | blindvt | khem, so.. given that current git supposedly is not worse CAS-wise than it was before, but only adds better code if gcc supports it, it should be fine |
19:08.54 | khem | Tartarus: I use minimal |
19:08.58 | khem | and angstrom |
19:08.59 | Tartarus | yes, i know |
19:09.11 | Tartarus | and i'm only hitting any RPATH errors on not minimal |
19:09.17 | khem | blindvt: that part is ok |
19:09.17 | Tartarus | ie the db recipe |
19:09.28 | khem | blindvt: problem happens with the move of atomics.h |
19:09.47 | khem | Tartarus: whats error |
19:10.03 | Tartarus | db is full of RPATH errors |
19:10.11 | blindvt | khem, how so? The very same atomic.h should be picked up, isn't it |
19:10.43 | Tartarus | sec, testing a fix for db itself and don't have a spare term open |
19:11.24 | khem | blindvt: I think it was not |
19:12.02 | khem | blindvt: I would like thumb1 to be alive in uclibc |
19:12.05 | GNUtoo|laptop | hmmm |
19:12.16 | GNUtoo|laptop | it would be easy if it was autotools |
19:12.23 | GNUtoo|laptop | but boost is not autootools but bjam |
19:12.31 | GNUtoo|laptop | I can't find where is the RPATH set |
19:12.37 | GNUtoo|laptop | so I'll try to prepare some commits |
19:12.44 | GNUtoo|laptop | and maybe someone else will fix it |
19:13.14 | blindvt | khem, there is only one arm-specific atomic.h and that never had thumb1 specific code, i.e. it's working as it was before (or not, with that race-window). Nothing changed, AFAICS |
19:16.48 | blindvt | khem, but anyway. If thumb1 nptl potential compare-and-swap race is the only thing you're not sure about i'm inclined to call it a release since it doesn't break on all 0 physical arm <= 5 boxes that i have :P |
19:17.29 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * rc391037389 10openembedded.git/recipes/bt-gps/bt-gps.bb: |
19:17.29 | CIA-47 | bt-gps: fix hardcoded paths, fix QA issues, use bindir/datadir variables |
19:17.29 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
19:18.18 | *** join/#oe Philippe (Philippe@84-231-124-204.elisa-mobile.fi) |
19:18.34 | blindvt | i'm quitting my job so have to cleanup my boxes there. bbl |
19:18.36 | blindvt | & |
19:19.36 | demigod2k | is there an easy way to tell bitbake to skip the packages that didn't work and make an image anyway with whatever did work? |
19:19.41 | khem | blindvt: sure we can always call for next release |
19:20.04 | khem | blindvt: and it should be called 1.0 as discussed and also bestowed upon by Erik |
19:20.12 | khem | blindvt: give me today |
19:20.18 | khem | I might find time to fix it for thumb |
19:20.27 | khem | in some hackish way atleast |
19:21.32 | *** join/#oe kevinsc (~a0214685@nat/ti/x-qwuxpihtvdukdekq) |
19:25.24 | Jay7 | otavio: my builds of meta-toolchain are fine |
19:26.18 | Tartarus | Jay7,what combo and is db built? |
19:27.01 | Jay7 | {angstrom-2010.x, minimal}/ben-nanonote/meta-toolchain with khem's gcc updates |
19:27.21 | Tartarus | something is up w/ insane... |
19:28.03 | Jay7 | db-5.0.21-r3 was built ok |
19:28.17 | Tartarus | which it shouldn't |
19:28.38 | Tartarus | try kaeilos |
19:28.43 | GNUtoo|laptop | Tartarus, do you have any idea on how to disable theses rpath stuff with bjam? |
19:28.51 | Jay7 | http://tinderbox.openembedded.net/packages/db/ |
19:29.06 | Jay7 | look there for statistic |
19:29.11 | Tartarus | yeah |
19:30.16 | Tartarus | http://tinderbox.openembedded.net/public/logs/qa/2202483.txt |
19:30.21 | Tartarus | how does everyone not hit it? |
19:31.17 | Jay7 | hm.. |
19:31.44 | GNUtoo|laptop | hmmm rpath issues are general? |
19:33.00 | Tartarus | maybe its a sysroot libtool thing |
19:33.10 | GNUtoo|laptop | ah ok |
19:33.13 | GNUtoo|laptop | then I'll wait |
19:33.37 | Tartarus | for? |
19:33.41 | GNUtoo|laptop | the fix |
19:33.42 | Tartarus | boost isnt autoconf is it? |
19:33.48 | GNUtoo|laptop | boost is bjam |
19:33.58 | Tartarus | so you need to fix it |
19:34.00 | GNUtoo|laptop | so I bet I've to fix it |
19:34.07 | GNUtoo|laptop | but I've no idea how |
19:34.15 | GNUtoo|laptop | JaMa, touched it the last time |
19:35.52 | GNUtoo|laptop | basically I've no idea on where is rpath generated |
19:35.55 | GNUtoo|laptop | and on how to fix |
19:36.08 | GNUtoo|laptop | I grepped for it in run.do_compile.N |
19:36.32 | GNUtoo|laptop | it found nothing |
19:37.03 | *** join/#oe timtimred (~meh@79-67-230-14.dynamic.dsl.as9105.com) |
19:37.55 | *** join/#oe denix (~denys@nat/ti/x-nivaaifwzcikdoez) |
19:42.45 | Philippe | demigod2k, try bitbake -k |
19:44.35 | demigod2k | Philippe: I tried that. Does work great for doing the rest of the packages but I think since the image is dependent on those which failed, it refuses to do the image :( |
19:44.57 | *** join/#oe playya (~playya@93.216.205.33) |
19:44.57 | *** join/#oe playya (~playya@unaffiliated/playya) |
19:45.44 | demigod2k | Philippe: my current solution is to generate the dependency graph, check the *.dot file, and try to remove everything (which might be under a lot of hierarchy like task-base, etc) which failed |
19:47.29 | Philippe | demigod2k, good luck with that. Might be easier to fix the package that failed |
19:48.12 | demigod2k | Ya that was the other approach. My saga for the week has been using an external toolchain. For console-image about 15-20 have failed in very difficult ways :( |
19:49.43 | demigod2k | I did manage to solve a few but others have become a real annoyance just in the way of getting my first image |
19:53.37 | *** join/#oe Jay7 (jay@95-29-109-151.broadband.corbina.ru) |
19:56.50 | GNUtoo|laptop | it seem that it's only during linking that there is an RPATH problem |
19:57.10 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
19:59.44 | Tartarus | RPATH is a link thing, yes |
20:01.37 | GNUtoo|laptop | yes I know |
20:01.43 | GNUtoo|laptop | but sometimes there are hacks |
20:01.45 | *** join/#oe Crofton (~balister@pool-74-107-167-114.ronkva.east.verizon.net) |
20:01.57 | *** join/#oe aloril (~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) |
20:02.00 | GNUtoo|laptop | like TARGET_CC += "--gnu-hash" |
20:02.16 | GNUtoo|laptop | the gnu hash is for linking |
20:02.31 | GNUtoo|laptop | but something it goes (uselessly) into compile stuff as well |
20:02.35 | GNUtoo|laptop | and is only used at linking |
20:04.01 | khem | Tartarus: I can try to reproduce it |
20:04.18 | khem | Tartarus: the issue would be mostly that db needs libtool love |
20:04.53 | GNUtoo|laptop | hmmm interesting variable RPATH_LINK |
20:10.32 | khem | Tartarus: I have a gcc niggle that I need to sort out |
20:10.41 | khem | then I have uclibc/thumb atomics |
20:10.54 | khem | then if time permits I will look into db |
20:11.21 | khem | wish to have a monster machine which could build OE in less than hr from scratch |
20:13.36 | blindvt | wishes to have an account on khem's super-fast dream machine :) |
20:14.18 | khem | blindvt: heh |
20:14.35 | blindvt | khem, pstaging helps if you don't play with the toolchain |
20:14.47 | khem | yeah pstaging is not for me |
20:14.57 | khem | unfortunately |
20:15.01 | khem | I hack toolchains |
20:15.26 | khem | oh with oe-core it might change a bit with individual sysroots |
20:18.15 | Jay7 | khem: 8-cored xeon with SSD |
20:18.36 | khem | yeah or even ramfs |
20:18.43 | Jay7 | my 6-cored phenom build console image about 1h20m |
20:18.55 | Jay7 | with single disk |
20:19.19 | khem | really thats impressive give phenom is like 4 times less in price than i7 |
20:19.24 | Jay7 | still have no ability to buy second HDD :( |
20:19.45 | khem | I have been meaning to built a box on my own |
20:19.53 | Jay7 | I have lowest phenom (1055T with 95TDP) |
20:19.54 | khem | new egg chickens out |
20:20.08 | khem | hmm nice |
20:20.20 | khem | we should also consider performance/dollar |
20:20.41 | Jay7 | btw, I'm doing benchmarking WRT bb threads/make threads |
20:21.40 | Jay7 | fastest build was 6/5 |
20:22.10 | Jay7 | 5/6 and 5/7 differs for 3-4 min |
20:25.57 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
20:26.10 | Jay7 | donate me 2x$70 and I'll provide full-time build-testing system :) |
20:26.18 | *** join/#oe eFfeM (~frans@j200125.upc-j.chello.nl) |
20:27.11 | Tartarus | khem, re db, 5.1.x is fine and backwards compat w/ 4.x / 5.0.x and already in poky, so i'm gonna go with that |
20:27.15 | Jay7 | may be even with queueing web-interface :) |
20:27.24 | Tartarus | that + --disable-rpath to gettext does it |
20:27.46 | khem | Tartarus: ok set DP to 5.1.x |
20:28.07 | Tartarus | gonna just drop the old ones and rfc is |
20:28.11 | Tartarus | s/is/it/ |
20:28.15 | khem | even better |
20:28.32 | khem | well may be keep 4.x around |
20:28.41 | khem | just if someone is locking it |
20:28.47 | Tartarus | externally? |
20:29.03 | khem | internally I am concerned |
20:29.08 | khem | externally I dont control |
20:29.08 | Tartarus | no one pins db |
20:29.12 | khem | ok |
20:30.04 | khem | I think oldest distro we care now is angstrom 2008 |
20:30.19 | Jay7 | +1 |
20:30.43 | khem | natty is definitely faster than f14 |
20:31.23 | Tartarus | kaeilos too? |
20:31.37 | Tartarus | but, non sysroot libtool distros have RPATH problems |
20:31.49 | Tartarus | Maybe that's a point in favor of not making it a fatal QA error yet |
20:32.16 | eFfeM | hi |
20:32.21 | khem | which distro does not use libtool |
20:32.21 | demigod2k | can you summarize what you're saying? |
20:32.39 | demigod2k | all I caught was the keywords and using external toolchain I've been fighting libtool/sysroot problems today |
20:33.18 | Tartarus | khem, 2.4? |
20:33.23 | Tartarus | angstrom 2008.1, kaeilos |
20:33.45 | khem | Tartarus: yes new keilos uses new libtool |
20:33.55 | khem | its only angstrom 2008 which still uses 2.2 |
20:34.51 | khem | hmm earlier once I went into workdir I could execute temp/run.do_* scripts and it would do stuff |
20:35.02 | khem | but now I have to go inside the builddir |
20:35.10 | kergoth | hmm |
20:35.10 | khem | otherwise it says nothing to build |
20:35.53 | kergoth | likely the bb.build changes, think its using cwd to subprocess to switch dirs instead of cd, should probably change it back so the run script is more usable |
20:35.55 | Tartarus | khem, 'kaeilos' is where I see errors |
20:36.21 | khem | kergoth: most likely |
20:36.35 | *** join/#oe rcf (~rcf@136.174-243-81.adsl-dyn.isp.belgacom.be) |
20:36.38 | khem | kergoth: I am using bb master |
20:36.40 | kergoth | khem: want to open a bug for it? |
20:37.06 | khem | kergoth: in bugzilla against bb ? |
20:37.14 | kergoth | yeah, just so we don't forget about it |
20:37.28 | khem | I think we abandoned bugz |
20:37.43 | khem | many devs think that |
20:37.45 | kergoth | heh, fair enough, i never really used it, though i should have |
20:37.48 | khem | I have no problem in filing |
20:37.59 | kergoth | okay, email to bitbake-dev instead? :) |
20:38.03 | khem | ok |
20:38.07 | kergoth | then it'll sit in inboxes until we fix it |
20:38.11 | kergoth | which is something |
20:38.16 | khem | heh |
20:38.42 | kergoth | going on vacation tomorrow until wed of next week |
20:38.50 | Crofton|work | yay |
20:38.52 | khem | wow good for you |
20:38.57 | khem | where are you going to |
20:40.27 | kergoth | just to visit my fiance's family, she hasn't seen them in a while |
20:40.37 | khem | ok cool |
20:41.00 | khem | anyone coming to atten ELC in SFO in apr |
20:41.24 | Crofton|work | I hope so |
20:42.15 | khem | I meant anyone from folks in this room :) |
20:42.34 | Crofton|work | I mean I hope I can |
20:42.37 | *** join/#oe mrj10 (~mrj10@mjlap.crhc.uiuc.edu) |
20:42.39 | khem | haha ok |
20:42.50 | *** part/#oe mrj10 (~mrj10@mjlap.crhc.uiuc.edu) |
20:42.52 | kergoth | I'd like to.. don't know if that'll happen though, will see |
20:43.02 | eFfeM | not me (& khem, enjoy your vacation) |
20:43.24 | khem | passes the enjoy part over to kergoth |
20:43.48 | kergoth | hehe |
20:44.26 | Jay7 | skip ELC but hope to attend on ELC-E |
20:45.48 | GNUtoo|laptop | sigh |
20:45.55 | GNUtoo|laptop | I don't understand bjam |
20:46.01 | GNUtoo|laptop | I don't know well rpath |
20:46.24 | GNUtoo|laptop | so I really want to fix but it seem that I will end with a lot of frustration and spend a lot of time on it |
20:46.46 | khem | GNUtoo|laptop: pass in -Wl,rpath,/usr/lib |
20:46.50 | khem | to LDFLAGS |
20:46.57 | GNUtoo|laptop | ah? |
20:46.59 | GNUtoo|laptop | I'll try |
20:47.05 | eFfeM | oops, misread, kergoth, enjoy your vacation |
20:47.08 | GNUtoo|laptop | good idea |
20:47.22 | khem | GNUtoo|laptop: btw -Wl,-rpath,/usr/lib |
20:47.58 | GNUtoo|laptop | yes because m rpath is not correct |
20:47.59 | GNUtoo|laptop | I know |
20:48.04 | GNUtoo|laptop | it point to sysroot's rpath |
20:48.07 | kergoth | hehe |
20:48.10 | GNUtoo|laptop | which...is kind of absent on target |
20:49.50 | otavio | khem: have you had time to look at the gcc-cross-sdk issue? |
20:50.19 | otavio | khem: it is reproducable with minimal and it seems to be i586 specific since Jay7 has built it fine. |
20:52.25 | khem | otavio: havent so far |
20:52.36 | khem | I will see if I have time today or tomorrow |
20:53.51 | GNUtoo|laptop | it seem better but now fails to build,hmmm |
20:55.23 | GNUtoo|laptop | I'll try to fix |
20:55.55 | otavio | khem: there's anything I can look at to check? I can do that easily here since I have rest built. |
20:57.22 | khem | otavio: it needs to be looked into I dont have anything on top of head that I could ask you to do |
20:57.26 | khem | ah |
20:57.30 | GNUtoo|laptop | thanks a lot |
20:57.41 | khem | try to reproduce it on arm e.g. in your env |
20:57.57 | otavio | khem: any machine to use? |
20:58.24 | khem | otavio: qemuarm |
20:58.41 | otavio | khem: just setting the machine and doing bitbake gcc-cross-sdk ought to be enough, right? |
20:58.47 | khem | yes |
20:59.10 | khem | it would make sure that its not related to something your settings are doing |
20:59.36 | *** join/#oe moi2134 (~moi@cpe-66-27-113-207.san.res.rr.com) |
21:00.10 | Jay7 | otavio: on which distro/machine have you error? |
21:00.24 | otavio | Jay7: minimal/i586-generic |
21:01.23 | Jay7 | I'll try to build gcc-cross-sdk |
21:01.47 | otavio | Jay7: nice .. I am building it for qemuarm |
21:10.46 | GNUtoo|laptop | I did that: |
21:10.48 | GNUtoo|laptop | LDFLAGS += "-Wl,-rpath,/usr/lib" |
21:10.56 | GNUtoo|laptop | in boost_1.45.0.bb |
21:10.58 | GNUtoo|laptop | and still |
21:11.19 | GNUtoo|laptop | ERROR: QA Issue with boost-date-time: package boost-date-time contains bad RPATH /usr/lib:/home/gnutoo/embedded/oe/oetmps/htcdream/sysroots/armv6-novfp-oe-linux-gnueabi/bin in file /home/gnutoo/embedded/oe/oetmps/htcdream/work/armv6-novfp-oe-linux-gnueabi/boost-1.45.0-r9.2/packages-split/boost-date-time/usr/lib/libboost_date_time.so.1.45.0 |
21:11.28 | GNUtoo|laptop | gcc.jam does that: |
21:12.38 | GNUtoo|laptop | "$(CONFIG_COMMAND)" -L"$(LINKPATH)" -Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,$(RPATH) -Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)" -o "$(<)" $(START-GROUP) "$(>)" "$(LIBRARIES)" $(FINDLIBS-ST-PFX) -l$(FINDLIBS-ST) $(FINDLIBS-SA-PFX) -l$(FINDLIBS-SA) $(END-GROUP) $(OPTIONS) $(USER_OPTIONS) |
21:12.46 | GNUtoo|laptop | so I wonder |
21:12.51 | GNUtoo|laptop | how to change that RPATH_LINK |
21:12.58 | GNUtoo|laptop | maybe I export it? |
21:14.29 | *** join/#oe duffolonious (~bryan@75-168-78-173.mpls.qwest.net) |
21:17.41 | GNUtoo|laptop | I'll try harder |
21:17.49 | GNUtoo|laptop | with the LDFLAGS variable |
21:19.34 | otavio | khem: it seems to build. |
21:19.45 | otavio | khem: Now I am even more confused hehehe |
21:20.05 | otavio | Packaged contents of gcc-cross-sdk into /home/otavio/hacking/embedded-linux/tmp/deploy/ipk/x86_64-armv5te-sdk/gcc-cross-sdk_4.5-r31.2+svnr168622_x86_64-armv5te-sdk.ipk |
21:22.01 | *** join/#oe morphis_ (~morphis@dslb-088-070-135-027.pools.arcor-ip.net) |
21:22.09 | GNUtoo|laptop | strange strange |
21:22.18 | GNUtoo|laptop | the compilation log doesn't contain anymore that: |
21:22.26 | GNUtoo|laptop | /usr/lib/home/gnutoo/embedded/oe/oetmps/htcdream/sysroots/armv6-novfp-oe-linux-gnueabi/bin |
21:23.06 | GNUtoo|laptop | bad grep |
21:23.07 | GNUtoo|laptop | it does |
21:23.24 | GNUtoo|laptop | and it's passed after that: |
21:23.28 | GNUtoo|laptop | -Wl,-rpath,/usr/lib |
21:23.37 | GNUtoo|laptop | so as it's passed after it it takes precedence |
21:24.06 | GNUtoo|laptop | maybe I pass to USER_OPTIONS |
21:24.07 | GNUtoo|laptop | ? |
21:24.18 | GNUtoo|laptop | but I don't know bjam at all |
21:24.34 | GNUtoo|laptop | last time I digged into it it was very hard and very undocumented |
21:27.20 | *** join/#oe woglinde (~heinold@g225006101.adsl.alicedsl.de) |
21:27.38 | otavio | khem: yes; it built fine. |
21:27.48 | otavio | khem: so it looks to be something related to i586 |
21:27.55 | kergoth | I wonder if i should make the oe.types bits a bit more picky, for consistency in recipes |
21:28.04 | *** join/#oe ALoGeNo (~alogeno@unaffiliated/alogeno) |
21:31.45 | GNUtoo|laptop | ok maybe I found how |
21:32.30 | blindvt | kergoth, i'm all for it, yes. What about auto-detection of the type btw? hmz, let me be noisy about un-typed vars |
21:33.11 | kergoth | well, right now, for example, the boolean type can be y/n, yes/no, true/false, t/f, whatever.. flexibility is good, but we all know that's just going to lead to inconsistency in the metadata.. |
21:33.42 | blindvt | oh darn.. let me first find a box where i can checkout bb and oe for a start |
21:34.34 | kergoth | I don't see autodetection being a good thing, better to be explicit |
21:37.50 | blindvt | cf.sf.net rejects ssh nowadays, great. HP and vanderbilt had boxes too, IIRC |
21:38.10 | blindvt | what a pita. back to square 1 |
21:41.21 | blindvt | what an irony. you've installed several petaflops worth of heating and now you're back to looking for an acceptable host with a gig of ram or two. |
21:41.39 | woglinde | ? |
21:41.45 | blindvt | nm |
21:43.39 | Jay7 | ERROR: Task 13 (/storage/oe/testbuilder/openembedded/recipes/gcc/gcc-cross-sdk_4.5.bb, do_compile) failed with exit code '1' |
21:43.42 | Jay7 | otavio: ^ |
21:44.26 | otavio | wow! NICE |
21:44.35 | otavio | Jay7: so you is able to reproduce it |
21:44.36 | otavio | good |
21:44.37 | Jay7 | i586-generic |
21:44.50 | otavio | Jay7: is it possible for it to be on the release arches? |
21:44.51 | Jay7 | | make[4]: *** [ios_init.lo] Error 1 |
21:45.06 | *** join/#oe zenlinux_laptop (~sgarman@masterfoo.zenlinux.com) |
21:49.08 | Jay7 | otavio: i don't know.. |
21:50.00 | Jay7 | hm.. strange that it is not shown on oestats |
21:50.32 | GNUtoo|laptop | sigh |
21:50.38 | GNUtoo|laptop | STILL.....the same issue |
21:51.55 | otavio | Jay7: I think toolchain-sdk is not built too ofthen |
21:52.27 | GNUtoo|laptop | it didn't replace a thing! |
21:52.30 | Jay7 | otavio: did you tried to set PARALLEL_MAKE="" for gcc-cross-sdk? |
21:52.41 | GNUtoo|laptop | -Wl,-R -Wl,"/home/gnutoo/embedded/oe/oetmps/htcdream/sysroots/armv6-novfp-oe-linux-gnueabi/bin" |
21:53.05 | GNUtoo|laptop | - echo "using gcc : target : ${CXX} : <cxxflags>${CFLAGS} ${CXXFLAGS} <linkflags>${LDFLAGS} ;" >> tools/build/v2/user-config.jam |
21:53.06 | GNUtoo|laptop | + echo "using gcc : target : ${CXX} : <cxxflags>${CFLAGS} ${CXXFLAGS} <linkflags>${LDFLAGS} <dll-path>${libdir} ;" >> tools/build/v2/user-config.jam |
21:53.11 | otavio | Jay7: no however I see no reason why it'd change something since it fail to find a library on /lib ... it seems to be looking at the /wrong/ path |
21:53.11 | GNUtoo|laptop | oops |
21:53.18 | Jay7 | ah |
21:53.30 | GNUtoo|laptop | ah no I pasted only 2 lines |
21:53.32 | GNUtoo|laptop | anyway |
21:53.42 | otavio | Jay7: libc_nonshared.a |
21:53.50 | Jay7 | otavio: then this is more likely libtool issue |
21:54.00 | otavio | Jay7: possibily |
21:54.20 | otavio | Jay7: but why it works for arm and fails for i586? |
21:54.31 | Jay7 | that is good question |
21:54.41 | GNUtoo|laptop | <PROTECTED> |
21:54.43 | Jay7 | I'm not skilled enough to answer :) |
21:55.05 | GNUtoo|laptop | sigh |
21:55.13 | GNUtoo|laptop | why do I have to go trough bjam again..... |
21:55.34 | otavio | Jay7: me neither |
21:56.08 | Jay7 | otavio: btw.. I'll try to build for qemux86 |
21:56.13 | Jay7 | it is i686 |
21:56.20 | Jay7 | let's check |
21:56.52 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * r4b134d69dc 10openembedded.git/classes/native.bbclass: (log message trimmed) |
21:56.52 | CIA-47 | native: fix duplicating virtclass-native entries in OVERRIDES |
21:56.52 | CIA-47 | A function was called from ${@} in OVERRIDES which was supposed to return the |
21:56.52 | CIA-47 | bits to prepend when in virtclass context, yet it *set* overrides instead, |
21:56.52 | CIA-47 | returning None. This resulted in 1) adding an extra virtclass-native to |
21:56.52 | CIA-47 | OVERRIDES each time it was expanded, and 2) appending None, causing |
21:56.53 | CIA-47 | 'localNone' to be in overrides rather than the expected 'local'. |
22:00.33 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
22:01.09 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
22:01.38 | mr_nice | GNUtoo|laptop: bjam has a option hardcode-dll-paths which is true by default. But I did not found out how to disable it. The docu says that it shuld be disabled when using stage instead of install as target. this was true but only on my host with x86 but not with the oe recipe |
22:02.00 | GNUtoo|laptop | ohhh |
22:02.06 | GNUtoo|laptop | thanks a lot!!!! |
22:03.24 | woglinde | kergoth yeah |
22:04.26 | mr_nice | GNUtoo|laptop: I hope it helps a bit |
22:05.22 | GNUtoo|laptop | if it works it will help a lot!!!! |
22:05.30 | GNUtoo|laptop | and I know how to pass options |
22:05.31 | GNUtoo|laptop | so.... |
22:06.08 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * r3023955451 10openembedded.git/classes/autotools.bbclass: |
22:06.08 | CIA-47 | autotools: symlink where we can |
22:06.08 | CIA-47 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
22:06.08 | CIA-47 | Acked-by: Khem Raj <raj.khem@gmail.com> |
22:06.08 | GNUtoo|laptop | I really hope it'll work |
22:06.09 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * re0528492ef 10openembedded.git/classes/autotools.bbclass: |
22:06.10 | CIA-47 | autotools: cleanup |
22:06.10 | CIA-47 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
22:06.10 | CIA-47 | Acked-by: Khem Raj <raj.khem@gmail.com> |
22:06.10 | kergoth | hmmmm |
22:06.11 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * r80549f1f6f 10openembedded.git/classes/autotools.bbclass: |
22:06.11 | CIA-47 | autotools: split out a oe_autoreconf function |
22:06.13 | CIA-47 | This functionality logically belongs in its own function, and it makes it |
22:06.13 | CIA-47 | easier to explicitly run against subdirs in certain cases. |
22:06.14 | CIA-47 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
22:07.55 | woglinde | good nite |
22:42.32 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * r1954f18268 10bitbake.git/lib/bb/runqueue.py: |
22:42.32 | CIA-47 | runqueue: pass a copy of the RunQueueStats to events |
22:42.32 | CIA-47 | This avoids cases where the stats are modified after the event is fired but |
22:42.32 | CIA-47 | before it's dispatched to the UI. |
22:42.32 | CIA-47 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
22:44.17 | *** join/#oe mrc3_ (~mrc3@nat/ti/x-fzqokjxhahiafctd) |
22:44.41 | *** join/#oe hwtechnik (~hwtechnik@h081217109005.dyn.cm.kabsi.at) |
22:46.45 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * r778571f155 10bitbake.git/lib/bb/runqueue.py: |
22:46.45 | CIA-47 | runqueue: simplify RunQueueStats.copy |
22:46.45 | CIA-47 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
22:49.46 | kergoth | yikes, cia is lagggging |
22:49.50 | kergoth | hrm |
22:53.44 | *** join/#oe CMoH (~cipi@95.76.68.223) |
22:53.45 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
22:54.42 | Jay7 | otavio: failed for qemux86 too |
22:54.50 | otavio | Jay7: good |
22:54.53 | Jay7 | http://tinderbox.openembedded.net/builds/127681/ |
22:55.52 | kergoth | hrm, probably shouldn't have pushed the autotools changes. doubt they'll break anything, haven't here, but i'll hold off on other things, no point risking problems in the release unnecessarily |
22:56.03 | kergoth | meh |
22:56.04 | Jay7 | hm... |
22:56.15 | Jay7 | oestats show two failed package |
22:56.24 | Jay7 | gcc-cross and gcc-cross-sdk |
22:56.41 | kergoth | hmm, if an oe build is making pandora skip, its probably time to back off on the number of threads, eh.. |
22:56.42 | kergoth | heh |
22:57.38 | Jay7 | kergoth: btw, is there any event saying that all tasks related to one package are completed? |
22:58.33 | Jay7 | ka6sox fear that pushing all data after build may cause high load |
22:58.46 | Jay7 | per task as well.. |
22:59.15 | Jay7 | so post per package may be something in the middle |
22:59.24 | kergoth | no, there used to be, but bitbake doesn't work on a recipe level nowadays |
22:59.29 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * r8eafb12208 10bitbake.git/lib/bb/siggen.py: |
22:59.30 | CIA-47 | siggen: add bb.data, bb.parse imports |
22:59.30 | CIA-47 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
22:59.30 | kergoth | (afaik, anyway) |
23:00.05 | Jay7 | I have thought about catching some task but seems different packages may have different tasks |
23:00.25 | Jay7 | e.g. do_rootfs for images |
23:01.06 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * re9e174e578 10bitbake.git/lib/bb/cooker.py: |
23:01.06 | CIA-47 | cooker: don't choke if we have nothing to parse |
23:01.06 | CIA-47 | If all our recipes were cached, there's no reason to fire off any parsing |
23:01.06 | CIA-47 | progress events at all. |
23:01.06 | CIA-47 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
23:01.10 | kergoth | yeah, there's no real way to know when a recipe is "done". this is another case where it'd be good to have a nice hook for "our build is going to run these tasks here..", since you could easily gather them together by FILE |
23:01.30 | kergoth | StampUpdate may be that, not sure, but its definitely not explicitly for that, afaik |
23:02.14 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * r718448e96d 10bitbake.git/lib/bb/ui/uihelper.py: |
23:02.14 | CIA-47 | uihelper: import bb.build, kill commented lines |
23:02.14 | CIA-47 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
23:03.28 | Jay7 | well.. then may be just check for collected data size per task and post when it is exceeded some limit |
23:04.15 | Jay7 | post'ing after the build have other good side - no need to post tasks changes |
23:05.26 | Jay7 | another good thing - we may have command-line tool that may post unsent data |
23:05.55 | Jay7 | e.g. build on notebook w/o inet, then get connection and post all data to oestats server |
23:07.59 | Jay7 | well.. kexecboot got new icons and font |
23:08.14 | Jay7 | no more that ugly font |
23:08.35 | Jay7 | going to merge changes |
23:17.53 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
23:19.45 | *** join/#oe ka6sox-farfarawa (ada4d7e9@nslu2-linux/ka6sox) |
23:19.56 | ka6sox-farfarawa | florian: you about? |
23:26.05 | khem | ka6sox-farfarawa: garnet is still down FYI |
23:26.06 | otavio | khem: the sdk.bbclass does nothing on the gcc-cross-sdk build since it failed to Jay7 too. |
23:26.19 | otavio | khem: and using same tree it has built fine for arm |
23:26.27 | otavio | khem: in my same build machine |
23:26.56 | khem | otavio: sdk class is inherited in -sdk recipes |
23:27.11 | khem | so it is not totally moot |
23:28.01 | otavio | khem: sure but if it was the cause it would be for arm too, no? |
23:28.22 | otavio | khem: and do not fail to Jay7 |
23:28.25 | khem | yes and no |
23:28.34 | khem | keep in mind that arm is entirely different than x86 |
23:28.44 | khem | but i586 is similar to x86 |
23:28.56 | khem | so there could be build host contamination somewhere |
23:29.03 | otavio | khem: right. I agreed. But Jay7 do not has it applied and it failed to him |
23:30.47 | otavio | khem: qt-tools-sdk depends on it for + -I${STAGING_DIR}/${HOST_SYS}${target_libdir}/dbus-1.0/include" |
23:31.28 | otavio | khem: and I couldn't hard code it since I were using micro. For minimal hardcoding it ought to work but seems wrong |
23:32.47 | khem | I would be vary of adding anything to classes |
23:32.52 | Jay7 | what exactly I have not applied? :) |
23:33.06 | otavio | Jay7: my sdk change |
23:33.09 | Jay7 | on tree with gcc updates |
23:33.12 | Jay7 | ah, ok |
23:33.39 | otavio | khem: if you want, I can try |
23:34.53 | otavio | khem: building. Will let you know if it changes anything tomorrow |
23:46.10 | GNUtoo|laptop | hi |
23:46.21 | GNUtoo|laptop | I spent hours of rebuilds |
23:46.26 | GNUtoo|laptop | and I still have bad rpath |
23:47.31 | GNUtoo|laptop | I tried many ways to pass the rpath |
23:47.34 | GNUtoo|laptop | some succeded |
23:47.36 | GNUtoo|laptop | but.... |
23:47.48 | GNUtoo|laptop | the "some" added to rpath instead of replacing |
23:47.55 | GNUtoo|laptop | at the end here's what I have: |
23:48.07 | GNUtoo|laptop | <loonycyborg> GNUtoo|laptop: It doesn't pass -rpath by default at all for me. |
23:48.13 | GNUtoo|laptop | <loonycyborg> So I have no idea where your rpath comes from. |
23:48.15 | GNUtoo|laptop | from #boost |
23:48.27 | GNUtoo|laptop | he uses boost trunk |
23:48.31 | GNUtoo|laptop | so there is 2 options |
23:48.41 | GNUtoo|laptop | or oe passed rpath in some ways I didn't see |
23:48.54 | GNUtoo|laptop | or....the trunk fix that issue |
23:54.08 | *** join/#oe mrj10 (~mrj10@63.252.64.254) |
23:55.43 | Tartarus | which DISTRO do you see this on? |
23:58.56 | GNUtoo|laptop | SHR |