| 00:01.27 | grg_ | khem, looks like my last bitbake world was with gcc 4.5. Comparing it with a previous log from gcc 4.4.4 shows almost no difference in the number of successful do_compile tasks. |
| 00:01.44 | khem | grg_: ok |
| 00:01.53 | grg_ | (differences probably accounted for by other changes in the tree) |
| 00:02.09 | khem | kergoth: you mean I dont have to bb.data.getVar LIBTOOL_HAS_SYSROOT |
| 00:03.22 | kergoth | yes |
| 00:03.28 | khem | kergoth: right right |
| 00:03.31 | kergoth | ['${LIBTOOL_HAS_SYSROOT}' == 'yes'] |
| 00:03.52 | kergoth | *slightly* less ugly that way ;) |
| 00:03.58 | khem | SYSROOTEXTRALIBDIRSED |
| 00:04.01 | khem | see that one |
| 00:04.11 | khem | now I need to conditionalize that |
| 00:09.47 | khem | kergoth: see if you can suggest some thing :) |
| 00:10.23 | khem | http://pastebin.com/xvVs5UZC |
| 00:14.32 | kergoth | oh, right |
| 00:14.35 | kergoth | in that case you have to use getVar |
| 00:14.46 | kergoth | because it has a ' in it, the surrounding '' gets screwed :) |
| 00:16.34 | kergoth | what i'd really like to do is make available the datastore as locals() |
| 00:16.51 | kergoth | so you could just FOO = "${@BPN + '-native'}" |
| 00:16.56 | kergoth | that'd be awesome. |
| 00:23.17 | *** join/#oe CMoH|notebook (~cipi@89.137.245.85) |
| 00:23.17 | *** join/#oe CMoH|notebook (~cipi@unaffiliated/c-moh) |
| 00:42.00 | playya__ | khem, are you still working on the gcc bug or could i go to bed? |
| 00:56.55 | *** join/#oe angelox_123 (~Angelo@201-93-199-140.dsl.telesp.net.br) |
| 01:10.29 | grg_ | playya__, git pull. it was fixed |
| 01:13.12 | playya__ | nope |
| 01:14.52 | grg_ | yep |
| 01:15.02 | *** join/#oe kgilmer (~kgilmer@dsl254-120-154.nyc1.dsl.speakeasy.net) |
| 01:16.43 | playya__ | grg_, this happend with HEAD about 1,5h ago: http://pastebin.com/tz2u7w97 |
| 01:17.13 | grg_ | playya__, git pull, it was fixed |
| 01:17.34 | playya__ | i already pulled f94d9bcd25 |
| 01:18.57 | *** join/#oe pcacjr_ (~pcacjr@unaffiliated/pcacjr) |
| 01:24.28 | grg_ | playya__, you probably just need to clean gcc-cross-initial |
| 01:25.13 | playya__ | this is what i did for testing: bitbake -c clean gcc gcc-cross gcc-cross-initial gcc-cross-intermediate && bitbake mplayer |
| 01:26.35 | grg_ | i just kicked off a bitbake gcc-cross, from scratch. So we'll see |
| 01:28.32 | playya__ | which machine? |
| 01:28.40 | grg_ | qemumipsel |
| 01:29.05 | playya__ | i think it's affiliated to armv7a |
| 01:30.00 | grg_ | well the patch applies to a file which looks target agnostic |
| 01:30.13 | grg_ | gcc-4.5/gcc/tree-vect-patterns.c |
| 01:32.41 | playya__ | I'm not a gcc expert |
| 01:37.36 | grg_ | Arm specific stuff would be in gcc-4.5/gcc/config/arm |
| 01:51.18 | grg_ | playya__, you need to clean something, i don't know what. gcc-cross-initial built fine for me |
| 01:52.13 | playya__ | i think initial built fine, too. but i used the same command |
| 01:53.45 | grg_ | your paste shows gcc-cross-initial failing at the exact line of the patch, with an error indicative of a stray semicolon at the point where the last commit fixed the stray semicolon |
| 01:55.45 | playya__ | hmm. then i missed the last commit |
| 01:55.56 | playya__ | i thought, i was up-to-date |
| 02:01.02 | *** join/#oe fraxinas (~quassel@p4FD65441.dip.t-dialin.net) |
| 02:09.31 | kergoth | oh wow |
| 02:09.39 | kergoth | making the metadata variables accessible as locals in snippets was extremely easy |
| 02:10.13 | kergoth | <PROTECTED> |
| 02:10.13 | kergoth | <PROTECTED> |
| 02:10.13 | kergoth | <PROTECTED> |
| 02:10.14 | kergoth | <PROTECTED> |
| 02:11.31 | kergoth | thoughts? |
| 02:13.20 | playya__ | kergoth, what do you think about this patch: http://github.com/playya/tslib/commit/b53df58338421391576ffe54f0a26a1b6dc6f843 |
| 02:13.59 | playya__ | except the " " <-> \t issue |
| 02:18.44 | kergoth | looks reasonable |
| 02:22.04 | playya__ | btw. how to implement multitouch in tslib? |
| 02:22.45 | playya__ | every implementation i read request only 1 sample |
| 02:33.03 | khem | playya__: you need to clean gcc |
| 02:33.32 | khem | playya__: bitbake -c clean gcc-cross gcc-cross-initial gcc-cross-intermediate eglibc eglibc-initial |
| 02:33.51 | khem | then bitbake <whatever you want> |
| 02:34.21 | playya__ | i think, i have to clean even more, because i pulled some more dependencies |
| 02:35.49 | khem | kergoth: interesting |
| 02:37.20 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 02:38.11 | kergoth_ | any thoughts on the direct access to vars as locals in snippets? |
| 02:38.14 | kergoth_ | ponders |
| 02:42.00 | *** join/#oe russ (foobar@ip70-176-251-1.ph.ph.cox.net) |
| 02:50.22 | playya__ | good night |
| 02:53.22 | *** join/#oe ALoGeNo (~alogeno@unaffiliated/alogeno) |
| 02:55.47 | *** join/#oe Spz0 (~a@184-76-62-129.war.clearwire-wmx.net) |
| 03:06.33 | grg_ | kergoth_, what's a snippet? |
| 03:06.38 | kergoth_ | ${@} |
| 03:06.43 | kergoth_ | inline python |
| 03:06.46 | kergoth_ | is what i'm referring to |
| 03:06.49 | grg_ | ah. cool |
| 03:06.57 | kergoth_ | so you owuldn't have to use getVar() in them |
| 03:06.58 | kergoth_ | or ${} |
| 03:07.03 | kergoth_ | but just directly access the vars |
| 03:07.21 | kergoth_ | PF = "${@PN + "-" + PV}" |
| 03:07.25 | kergoth_ | or what have you |
| 03:07.54 | grg_ | that would certainly make things more readable |
| 03:07.59 | kergoth_ | yeah, thats my thought |
| 03:08.03 | kergoth_ | reduce the ugliness |
| 03:08.09 | kergoth_ | bit more straightforward |
| 03:08.21 | kergoth_ | only works in those, not python tasks, which i think is best, those can use getVar() easily enough |
| 03:09.20 | kergoth_ | http://github.com/kergoth/OE-Signatures/commit/49cf79bb545c731147ae552967484aa133070d6f shows the implementation in the signature code, the implementation in bitbake itself would be no more difficult |
| 03:10.23 | *** join/#oe kevinsc (~a0214685@nat/ti/x-carktktimtiwlvki) |
| 03:17.28 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
| 03:17.45 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |
| 03:25.49 | *** part/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 03:36.58 | *** join/#oe pcacjr_ (~pcacjr@187.78.159.117) |
| 03:36.58 | *** join/#oe pcacjr_ (~pcacjr@unaffiliated/pcacjr) |
| 03:39.11 | *** join/#oe zenlinuxPDX (~sgarman@c-76-105-143-140.hsd1.or.comcast.net) |
| 03:40.56 | *** join/#oe borg__ (~olaf@p54869950.dip0.t-ipconnect.de) |
| 03:42.09 | *** join/#oe rednul_ (~rednul@host-174-45-250-246.bln-mt.client.bresnan.net) |
| 03:42.17 | kergoth_ | huh |
| 03:42.24 | kergoth_ | implemented it in bitbake and started using it in bitbake.conf |
| 03:42.25 | kergoth_ | works great |
| 03:44.30 | grg_ | the only downside i see is that it will make the dev branch depend on bitbake head |
| 03:45.11 | grg_ | but everyone syncs their oe and bitbake trees simultaneously, right? |
| 03:55.02 | kergoth_ | oh, i wouldn't change OE to use it until it bumps its minimum bitbake version to one that includes the feature |
| 03:55.16 | kergoth_ | we haven't even bumped the minimum to 1.10 yet, and this would be going into whatever comes after 1.10 (1.12, likely) |
| 03:55.21 | kergoth_ | :) |
| 03:55.38 | kergoth_ | but thats true for every change to bitbake |
| 03:59.19 | grg_ | i think we need to have a new stable branch, so that this sort of thing can be merged into the dev branch sooner |
| 03:59.42 | kergoth_ | agreed |
| 03:59.50 | kergoth_ | i also think bitbake needs a proper release cycle |
| 04:00.02 | kergoth_ | right now its whenever we feel like it |
| 04:00.11 | grg_ | things are currently looking quite stable, so it might be a good time to propose such a thing |
| 04:00.26 | kergoth_ | really likes cbrake's testing stuff |
| 04:00.39 | grg_ | yes, its worked marvelously |
| 04:01.43 | CIA-68 | 03Chris Larson <chris_larson@mentor.com> 07master * r8d661ce0c3 10bitbake.git/lib/bb/data_smart.py: |
| 04:01.43 | CIA-68 | Fix __getitem__ for DataSmart |
| 04:01.43 | CIA-68 | Ensure it raises KeyError for a missing key, this is required to use this as a |
| 04:01.43 | CIA-68 | mapping in various places, e.g. as locals in an eval. |
| 04:01.43 | CIA-68 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 04:01.48 | CIA-68 | 03Khem Raj <raj.khem@gmail.com> 07master * rf264cb6d43 10bitbake.git/lib/bb/fetch/ (bzr.py cvs.py git.py hg.py svn.py): |
| 04:01.48 | CIA-68 | fetchers: Use tar --exclude pattern to remove SCM files |
| 04:01.48 | CIA-68 | This option will exclude the SCM metadata from tar files. |
| 04:01.48 | CIA-68 | Tested with gcc where svn tar which used to be 156M for gcc 4.5 |
| 04:01.49 | CIA-68 | is now 77M |
| 04:01.49 | CIA-68 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 04:01.50 | CIA-68 | 03Chris Larson <chris_larson@mentor.com> 07master * r606fa1fd97 10bitbake.git/lib/bb/data_smart.py: |
| 04:01.50 | CIA-68 | Access metadata vars as locals in python snippets |
| 04:01.51 | CIA-68 | Example: |
| 04:01.51 | CIA-68 | FOO = "bar" |
| 04:01.52 | CIA-68 | BAR = "${@FOO + '/baz'}" |
| 04:01.52 | CIA-68 | ${BAR} == "bar/baz" |
| 04:01.53 | CIA-68 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 04:03.56 | khem | kergoth_: Cool |
| 04:04.05 | kergoth_ | sorry for the delay :) |
| 04:04.14 | khem | kergoth_: how would I use this new feature for my purpose |
| 04:04.44 | kergoth_ | we can't use it until the version minimum is bumped, of course, but in your case you'd just use the var name directly |
| 04:04.58 | kergoth_ | ${@["foo", "bar"][LIBTOOL_USES_SYSROOT == 'foo'] |
| 04:04.59 | kergoth_ | } |
| 04:05.23 | kergoth_ | thinks this will clean up some of our config files nicely |
| 04:05.25 | khem | ah right |
| 04:05.36 | khem | anyway I have more ugliness already |
| 04:05.39 | khem | working |
| 04:05.42 | kergoth_ | as usual :) |
| 04:05.50 | kergoth_ | hard to avoid in some cases, nature of the beast |
| 04:06.07 | khem | so now I guess I should be able to switch libtools with one var |
| 04:06.08 | khem | lets see |
| 04:06.13 | kergoth_ | nice |
| 04:06.32 | khem | ideally I would have kicked 2.2 out |
| 04:06.48 | khem | just for the sheer fugliness it brings in now |
| 04:07.38 | kergoth_ | yeah, its unfortunate that we're limited in that way right now |
| 04:08.17 | khem | yeah OE is less agine |
| 04:08.21 | khem | agile |
| 04:08.28 | khem | we take too much crap on us |
| 04:08.47 | khem | ok so someone broke images |
| 04:09.04 | khem | now I dont see /lib/modules being packaged into the image files |
| 04:09.10 | khem | wtf |
| 04:09.44 | khem | and obviously udev cries for mama |
| 04:10.13 | khem | kergoth: where is this code for embedding modules into image |
| 04:11.05 | khem | hmmm I am using 2.6.34 and some one applied a patch and the modules are now installed in lib/module/2.6.34.7 |
| 04:11.22 | khem | instead of lib/modules/2.6.34 |
| 04:11.25 | khem | when it worked |
| 04:11.48 | khem | kergoth: the recipe say linux_2.6.34.bb still could that be it |
| 04:15.57 | kergoth_ | so PV is 2.6.34 but the kernel version isn't that |
| 04:16.04 | khem | yep |
| 04:16.13 | kergoth_ | dunno if thats an issue or not without looking at the packaging bits, i assume it is since its broken for you :) |
| 04:16.14 | khem | its 2.6.34.7 |
| 04:16.33 | khem | yeah I reverting a patch |
| 04:16.50 | khem | 5786f08ba6066e9af60104c5d5606c106e8df7d2 |
| 04:16.55 | khem | this one |
| 04:17.59 | khem | kergoth_: I was afraid libtool broke it o.0 |
| 04:18.10 | khem | is paranoid |
| 04:24.58 | *** join/#oe rphillips (~rphillips@hera.xen.prgmr.com) |
| 04:27.49 | *** join/#oe rphillips (~rphillips@unaffiliated/rphillips) |
| 04:30.23 | *** join/#oe koobe_ (~koobe@dsl-trebrasgw2-fe4df900-31.dhcp.inet.fi) |
| 05:02.28 | *** join/#oe denix (~denys@nat/ti/x-bnjnapqebxyllhtj) |
| 05:02.31 | *** join/#oe mrc3 (~mrc3@nat/ti/x-csochhjlejwpqryh) |
| 05:05.32 | *** join/#oe mrc3 (~mrc3@nat/ti/x-rcdayqtlxcpdpwgq) |
| 05:16.55 | *** join/#oe polyonymous (~hacker@g230192031.adsl.alicedsl.de) |
| 05:18.03 | *** join/#oe rednul_ (~rednul@host-174-45-250-246.bln-mt.client.bresnan.net) |
| 05:19.08 | *** join/#oe Aarti (~Aarti@122.166.11.13) |
| 05:29.14 | *** join/#oe dth (~dth@a89-182-146-32.net-htp.de) |
| 05:42.12 | *** join/#oe harsh (~harsh@122.248.161.59) |
| 05:42.59 | *** join/#oe rednul_ (~rednul@host-174-45-250-246.bln-mt.client.bresnan.net) |
| 05:44.24 | *** join/#oe d_th (~dth@a89-183-27-135.net-htp.de) |
| 05:46.23 | *** join/#oe methril (~methril@189.27.129.162.dynamic.adsl.gvt.net.br) |
| 05:46.49 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
| 06:28.31 | *** join/#oe mrc3_ (~ddiaz@189.157.108.174) |
| 06:30.19 | *** join/#oe zecke (~ich@91-64-127-39-dynip.superkabel.de) |
| 06:33.29 | eFfeM_work | gm |
| 06:33.51 | *** join/#oe radhermit (~radhermit@gentoo/developer/radhermit) |
| 06:39.48 | *** join/#oe B_Lizzard (~havoc@athedsl-422791.home.otenet.gr) |
| 06:42.58 | *** join/#oe grund (~grund@64.244.156.164) |
| 06:47.13 | CIA-68 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r5b3a4eb994 10openembedded.git/recipes/mesa/ (5 files): |
| 06:47.13 | CIA-68 | mesa: move mesa-progs from mesa-common.inc to mesa-version.inc |
| 06:47.13 | CIA-68 | * for mesa-7.9 and newer there are mesa-demos in separate repository |
| 06:47.13 | CIA-68 | * I'll add recipe for latest mesa-demos later |
| 06:47.13 | CIA-68 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 06:48.38 | *** join/#oe radhermit (~radhermit@gentoo/developer/radhermit) |
| 06:53.57 | JaMa | hi, someone already working on talloc recipe? |
| 06:56.28 | JaMa | hmm someone tried outside OE http://samba.2283325.n4.nabble.com/cross-compiling-talloc-with-waf-td2482920.html |
| 07:06.00 | *** join/#oe Aarti (~Aarti@122.166.11.13) |
| 07:06.36 | *** join/#oe Proxyles (~henrik@c-0890e255.56-4-64736c14.cust.bredbandsbolaget.se) |
| 07:22.32 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
| 07:29.41 | mckoan | good morning |
| 07:32.29 | *** join/#oe jcrouse (~nobody@207-114-132-30.static.twtelecom.net) |
| 07:33.37 | *** join/#oe xeon-enouf (~xeon-enou@unaffiliated/xeon-enouf) |
| 07:33.51 | *** join/#oe Heinervdm (~thomas@pD9E17854.dip.t-dialin.net) |
| 07:40.34 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 07:42.26 | *** join/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl) |
| 07:46.40 | *** join/#oe CosmicPenguin (~nobody@rrcs-67-52-130-30.west.biz.rr.com) |
| 07:58.57 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 07:58.57 | *** join/#oe kristoffer (~kristoffe@c-fedae555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 08:04.07 | JaMa | khem: not sure if it's result of latest gcc patch, but today I got ICE while building samba_3.2.15 http://tinderbox.openembedded.org/packages/816608/ |
| 08:04.55 | filip | khem: I lost my link yesterday. Do you think I should add http://pastebin.com/KiMhk4hx to (e)glibc recipes? |
| 08:11.46 | CIA-68 | 03Marco Cavallini <m.cavallini@koansoftware.com> 07org.openembedded.dev * r9febf6a6bf 10openembedded.git/recipes/linux/linux_2.6.28.bb: linux_2.6.28.bb: changed link to Ronetix' patch for machine ronetix-pm9263 |
| 08:20.07 | hrw | morning |
| 08:20.18 | *** join/#oe dth_ntb (~dth@a89-183-27-135.net-htp.de) |
| 08:36.21 | *** join/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl) |
| 08:43.35 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:44.26 | florian | good morning |
| 08:55.01 | eFfeM_work | hi florian |
| 08:55.27 | eFfeM_work | florian, i saw you created the dockstar machine, are you actively working on it ? |
| 08:58.20 | florian | eFfeM_work: hi |
| 08:58.24 | eFfeM_work | i'm the maintainer of sheevaplug and openrd-client; did spent too much time on other things, but the linux kirkwood tree seems not active any more, saw you used 2.6.35, i want to move sheeva and openrd also to 2.6.35; then come with a patch to update conf/machine/include/kirkwood.inc to make linux the default kernel |
| 08:59.10 | florian | eFfeM_work: "actively" depends on free time but yes I'm trying to do useful things with this device. |
| 08:59.10 | eFfeM_work | i can alsoimage we move EXTRA_IMAGECMD_jffs2 to kirkwood.inc |
| 08:59.42 | eFfeM_work | yeah, same here with sheeva, actually dockstar is a nice device which can be obtained cheaply nowadays |
| 09:01.01 | florian | I don't know offhand if this would work for all kirkwood, but for the "default" ones used in Sheevaplug, Dockstar and TK71 2.6.35 seems to sopport very well. The dockstar patch is not more then the machine file. |
| 09:02.01 | eFfeM_work | yeah saw that |
| 09:02.12 | florian | The jffs2 I would leave in the device files. This makes it more clear that it depends on the actual flash used in the device and not the CPU. |
| 09:02.36 | florian | These devices are really cheap now... got mine for EUR 20 in a shop. |
| 09:02.36 | eFfeM_work | sheeva had one or two additional patches, actually I already did those and booted it, didn't get to consolidatingthat |
| 09:02.45 | eFfeM_work | wrt jffs2: you're right |
| 09:02.47 | eFfeM_work | eur 20 is nice! |
| 09:03.04 | eFfeM_work | guess wd is dropping the product |
| 09:03.25 | eFfeM_work | at some point in time marvell suggested a $50 plug |
| 09:03.30 | eFfeM_work | this is better |
| 09:04.15 | florian | There seem to be several similar devices around - Seagate has one for 3.5" disks now and one where two 2.5" SATA drives fit into. |
| 09:04.48 | eFfeM_work | that would be cool, only thing missing in my sheeva is sata, taht's also why i got the openrd client |
| 09:05.01 | eFfeM_work | which btw needs some more work as e.g. the video driver has not been mainlined |
| 09:05.12 | florian | Hardware hackers seem to like it... there are PCB designs around for adding another Ethernet, SD and such things :) |
| 09:05.24 | eFfeM_work | cool, do you have a url ? |
| 09:06.21 | florian | The best collection I'm aware of is here: http://www.mikrocontroller.net/articles/Dockstar but German only :-( |
| 09:07.31 | florian | The OpenRD is nice... I wonder if we have one here at the office :-) |
| 09:09.54 | ynezz | hm, that openrd looks really nice |
| 09:09.59 | ynezz | and it's nice price |
| 09:10.28 | filip | wifi version would be nice |
| 09:10.36 | ynezz | considering I'm using this http://www.embeddedarm.com/products/board-detail.php?product=ts-7800 |
| 09:12.03 | JDuke127 | hallo |
| 09:12.12 | ynezz | filip: you can add wifi with usb stick easily |
| 09:12.59 | filip | ynezz: well I could use an old pc as well ;). This thing is all about completeness in a small box |
| 09:13.05 | eFfeM_work | florian: thanks for the link, I can read german (& speak a tiny bit) |
| 09:13.14 | ynezz | filip: and power consumption! |
| 09:13.23 | eFfeM_work | florian btw did you get it in an internet shop? |
| 09:13.46 | filip | and fancyness! |
| 09:13.58 | filip | I am using an old compaq deskpro for stuff like this |
| 09:14.03 | filip | it pulls around 30W |
| 09:14.19 | filip | has room for two 3.5" drives, has ethernet, pci, usb and everything |
| 09:14.27 | filip | and costs like... 5EUR now |
| 09:14.33 | eFfeM_work | <PROTECTED> |
| 09:14.44 | eFfeM_work | disadvantage of openrd is size |
| 09:15.30 | eFfeM_work | 30w, a sheeva with usb hd will probably use less than 10 w |
| 09:15.31 | ynezz | but the advantage of ts7800 board is their availability |
| 09:17.01 | ynezz | 30W is quite a lot I think for 365/24/7 |
| 09:17.28 | JDuke127 | hi , i m having problem on toolchain sdk C++ hello.c , i tried to compile code : http://pastebin.com/wvnpg2Gr with this command , but when i add clutter.h i got huge errors as shown here http://pastebin.com/HqdtJmDR , whats wrong ? someone can help ? |
| 09:17.53 | zecke | JDuke127: you really need to improve your reading skills |
| 09:18.02 | zecke | JDuke127: why do you think it should find clutter.h like this? |
| 09:18.11 | eFfeM_work | florian: found teh atelco link for dockstar, they noticed the thing is hot so now it is eur 29.90 |
| 09:18.23 | zecke | JDuke127: i told you yesterday to use devshell, and then pkg-config --cflags NameOfClutterModule to get the right include paths |
| 09:19.05 | filip | ynezz: well the disks need power |
| 09:19.12 | JDuke127 | zecke , it works fine with devshell yes but , someone told me to install bitbake toolchain |
| 09:19.17 | filip | ynezz: and with ext3 it's not easy to spin them down |
| 09:19.41 | zecke | JDuke127: well, please explain to me why <clutter.h> should work? |
| 09:19.57 | JDuke127 | zecke: and i installed toolchain sdk "bitbake meta-toolchain" |
| 09:20.09 | JDuke127 | i m not using standard OE arm eabi cc |
| 09:20.16 | JDuke127 | its meta toolchain |
| 09:20.21 | zecke | JDuke127: that is not answering the question |
| 09:20.22 | JDuke127 | i set PATH |
| 09:20.41 | JDuke127 | i donno , yes it works on devshell fine |
| 09:21.15 | zecke | JDuke127: why do you think <clutter.h> should work? |
| 09:21.40 | JDuke127 | i did "opkg-target libclutter" |
| 09:22.49 | zecke | JDuke127: seriously, before asking others for help you should do something yourself. Do you even have a clutter.h in the unpacked toolchain? find /path/to/toolchain -name clutter.h |
| 09:23.55 | JDuke127 | i looked inside include , it has clutter.h , yes |
| 09:24.29 | JDuke127 | zecke , did you used meta-toolchain before ? |
| 09:26.02 | JDuke127 | zecke , i got clutter.h /home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/clutter-1.0/clutter/clutter.h |
| 09:27.41 | zecke | JDuke127: yes, but that is not what you include... you should compile with foo-bar-g++ `pkg-config --cflags clutter-1.0` -o myapp main.cc |
| 09:28.11 | JDuke127 | hmm g++ , not gcc |
| 09:28.27 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 09:28.29 | zecke | JDuke127: the compiler only searches in /home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/... it will not magically go into clutter-1.0/clutter |
| 09:29.04 | zecke | JDuke127: well, you used C++ above, but for including it does not matter... on top of that the toolchain is unlikely to be relocatable... it was built to be in /usr/local/angstrom |
| 09:30.51 | JDuke127 | but my compiler recognizes , clutter.h , there is no error like , Eg: "File not found 'clutter.h' " , |
| 09:31.11 | JDuke127 | i think there r some conflicts or C or C++ err |
| 09:32.03 | zecke | JDuke127: it is a string, how should it not recognize it? |
| 09:32.45 | JDuke127 | when i do this |
| 09:32.48 | JDuke127 | kadirbasol@kadirlinux:~/OE/sdk/usr/local/angstrom/arm$ arm-angstrom-linux-gnueabi-g++ ~/Desktop/hello.cc /home/kadirbasol/Desktop/hello.cc:4:21: error: clutter.h: No such file or directory |
| 09:32.55 | zecke | JDuke127: use strace to see where your compiler is searching for clutter.h... it is certainly not in /home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/clutter.h |
| 09:32.56 | JDuke127 | but i add |
| 09:33.10 | JDuke127 | arm-angstrom-linux-gnueabi-g++ ~/Desktop/hello.cc -I /home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/clutter-1.0/clutter |
| 09:33.31 | JDuke127 | then , i got |
| 09:33.34 | JDuke127 | home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/clutter-1.0/clutter/clutter-stage.h:255: error: âheightâ was not declared in this scope /home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/clutter-1.0/clutter/clutter-stage.h:266: error: âG_END_DECLSâ does not name a type |
| 09:33.38 | JDuke127 | and many more errors... |
| 09:34.03 | JDuke127 | maybe clutter library broken |
| 09:34.07 | zecke | JDuke127: well, in that case the clutter authors messed up their G_BEGIN_DECLS/G_END_DECLS. |
| 09:34.39 | JDuke127 | ok |
| 09:34.45 | JDuke127 | i try devshell back now |
| 09:34.46 | zecke | JDuke127: What is your goal? You do not seem to have a good understanding of C/C++, compiling, toolchains. Maybe you should refocus on the problem you want to solve? |
| 09:35.09 | JDuke127 | now i do |
| 09:35.09 | JDuke127 | bitbake -c devshell clutter |
| 09:35.17 | zecke | JDuke127: even for the cross toolchain... you need to use `pkg-config --cflags --libs clutter-1.0` |
| 09:35.45 | *** join/#oe kgilmer (~kgilmer@dsl254-120-154.nyc1.dsl.speakeasy.net) |
| 09:35.47 | zecke | JDuke127: we use pkg-config to 'find' the right include paths... and probably the preferred way to include clutter.h then is to use clutter/clutter.h |
| 09:38.10 | JDuke127 | zecke , it compiles on devshell its ok |
| 09:38.30 | JDuke127 | i just get 1 warning |
| 09:38.31 | JDuke127 | http://pastebin.com/6i2wdmMm |
| 09:38.37 | JDuke127 | this warning makes problem ? |
| 09:38.57 | JDuke127 | warning: libc.so, needed by /home/kadirbasol/OE/build/tmp-igep0020/sysroots/x86_64-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/lib/libgcc_s.so, not found (try using -rpath or -rpath-link) |
| 09:40.22 | zecke | JDuke127: warning, most likely an issue with the binutils 2.18.. I have sent an email to the oe-dev list but got little response |
| 09:41.02 | JDuke127 | hmm when we update binutils , problem will be solved |
| 09:42.17 | zecke | JDuke127: well, it is a warning... nothing to worry about |
| 09:44.10 | JDuke127 | ok |
| 09:44.22 | JDuke127 | now i ve uploaded my binary to my card |
| 09:44.25 | JDuke127 | i ve ran app |
| 09:44.49 | JDuke127 | this time clutter seems broken : ClutterEGL-WARNING **: eglChooseConfig failed , ClutterEGL-CRITICAL **: Unable to find suitable GL visual. |
| 09:45.12 | JDuke127 | i got this errors in loop |
| 09:45.20 | JDuke127 | no display shown |
| 09:46.03 | zecke | JDuke127: well, you are in an engineering channel. You will need to think before you post questions |
| 09:46.43 | zecke | JDuke127: did you at least google gfor eglChooseConfig? |
| 09:48.30 | JDuke127 | yes |
| 09:49.43 | eFfeM_work | admires zecke's patience :P |
| 09:50.10 | zecke | JDuke127: from where do you start it? do you have an xserver running or such? |
| 09:53.42 | JDuke127 | no i dont like X11 |
| 09:53.45 | JDuke127 | i hate X11 |
| 09:53.53 | JDuke127 | i m using pure framebuffer on console |
| 09:54.02 | JDuke127 | and i can run simple OGL Apps |
| 09:54.08 | JDuke127 | but not clutter running |
| 09:54.10 | JDuke127 | EGL |
| 09:55.38 | zecke | JDuke127: and you are sure that clutter has an EGL backend != ClutterEGLX that does not require X11? |
| 09:56.53 | JDuke127 | how can i do this config ? |
| 09:57.06 | eFfeM_work | read the source luke |
| 09:57.16 | eFfeM_work | or ask in a clutter forum |
| 09:57.43 | zecke | eFfeM_work: that is mean to ask him to pester the clutter devs |
| 09:57.49 | *** join/#oe DJWillis (djwillis@cpc3-bath5-2-0-cust220.aztw.cable.virginmedia.com) |
| 09:58.07 | zecke | JDuke127: well, read the source.. search for ClutterEGL and calls to eglChooseConfig |
| 10:00.32 | *** join/#oe CMoH|notebook (~cipi@unaffiliated/c-moh) |
| 10:06.26 | *** join/#oe harsh (~harsh@122.248.161.59) |
| 10:08.28 | *** join/#oe CMoH-notebook (~cipi@89.137.245.85) |
| 10:08.28 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 10:17.16 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 10:18.00 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
| 10:22.34 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rf1822d1110 10openembedded.git/recipes/opkg/opkg-collateral.bb: opkg-collateral: make angstrom use SHR tmpdir fix and change package arch to all |
| 10:49.19 | XorA | guesses the ltg planet got stuck sometime in September and stopped updating |
| 10:49.33 | XorA | florian: is the ltg planet stuck? |
| 10:52.43 | florian | i'll take a look |
| 10:54.49 | *** join/#oe methril_work (~methril@201.35.65.90) |
| 10:58.37 | XorA | thinks OE devs are normally more verbose than a months gap :-) |
| 11:00.24 | hrw | ;D |
| 11:03.42 | XorA | florian: that looks better :-) |
| 11:04.32 | florian | indeed... looks liek there is a problem with the cronjob |
| 11:06.55 | tasslehoff | I have added qt-embedded to my image like this: http://pastebin.com/Lve9QqfE, cherry picking what I need. Now want to use qt4-embedded-gles, but I don't know how to tell it to compile that one instead of qt4-embedded. Is this something I do in DEPENDS? |
| 11:11.33 | *** join/#oe methril_work (~methril@201.35.65.90) |
| 11:13.11 | *** join/#oe GNUtoo|laptop (~gnutoo@host245-55-dynamic.180-80-r.retail.telecomitalia.it) |
| 11:23.13 | *** join/#oe mawillia (~mikew@rrcs-24-39-249-130.nys.biz.rr.com) |
| 11:25.44 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r77869f4261 10openembedded.git/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb: |
| 11:25.44 | CIA-68 | omap3-sgx-modules: update to latest SDK release and add ti816x support |
| 11:25.44 | CIA-68 | Signed-off-by: Koen Kooi <k-kooi@ti.com> |
| 11:25.58 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rd50346e98e 10openembedded.git/recipes/powervr-drivers/libgles-omap3.inc: |
| 11:25.58 | CIA-68 | libgles-omap3: add ti816x support and fix packaging |
| 11:25.58 | CIA-68 | Signed-off-by: Koen Kooi <k-kooi@ti.com> |
| 11:27.04 | mawillia | Is there any documentation about setting up a ipk server for custom packages (conf file formats, http server requirements, etc)? |
| 11:37.14 | eFfeM_work | mawillia: it is just a regular http server |
| 11:40.49 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
| 11:41.05 | mawillia | OK, so other than the .ipk file, what needs to be there to get picked up in the "opkg update" call? Looks like a compressed list get's pulled down. What needs to be in it? (I'm a noob, so if there's an FM, I'll be glad to go read it). |
| 11:44.51 | *** join/#oe GarthPS (~quassel@92.102.66.79) |
| 11:46.36 | eFfeM_work | mawillia: you also need package files, if you do a bitbake package-index (or something like that; don't to this very often) everything you need ends up in tmp/deploy/ipk/* |
| 11:46.43 | eFfeM_work | if I am correct |
| 11:48.27 | eFfeM_work | mawillia: and read this http://docs.openembedded.org/usermanual/html/image_class.html |
| 11:48.33 | eFfeM_work | especially the method 2 secion |
| 11:48.56 | ant_work | eFfeM_work: hi |
| 11:49.06 | eFfeM_work | hi ant_work |
| 11:49.14 | eFfeM_work | how are you doing? |
| 11:49.25 | ant_work | I launched a first attack to /linux for pruning ;) |
| 11:49.36 | eFfeM_work | great :-) |
| 11:49.46 | ant_work | very busy with biz, not enough time to go in depth |
| 11:50.18 | eFfeM_work | pity, but sounds familiar |
| 11:50.31 | eFfeM_work | did you plan to come to elc/oedem? |
| 11:50.32 | ant_work | next stepl would be remove the duplicate patches shared between similar linux recipes |
| 11:50.47 | ant_work | i.e. extending FILESPATHPKG |
| 11:51.00 | ant_work | same could be done for linux boot logo |
| 11:51.43 | eFfeM_work | i have some mixed feelings on removing dup patches, it is nice filewise, but it becomes harder to find if a file is unused |
| 11:52.08 | eFfeM_work | and I really dislike FILESPATHPKG that refer to dirs for other versions |
| 11:52.09 | ant_work | true, best would be move the recipe+patches to obsolete |
| 11:52.23 | eFfeM_work | common patches could go to linux/ dir or so |
| 11:52.30 | ant_work | but the case linux-kexecboot -> linux is not the only one |
| 11:52.50 | ant_work | actually is just different defconfig |
| 11:53.06 | ant_work | (and extra .inc file) |
| 11:53.07 | eFfeM_work | but i also saw that some glibc recipes extended the path to add glibc-2.4 or so which is a recipe for errors |
| 11:53.16 | ant_work | :/ |
| 11:53.47 | eFfeM_work | it might also be interesting to merge linux and linux-libc-headers |
| 11:54.10 | ant_work | well, in the case there are many recipes, best would be to insulate the patch of each in a subdir |
| 11:54.23 | ant_work | general case being putting the shared files in /files |
| 11:54.33 | tasslehoff | If I clean "qt4-embedded" and then put "qt4-embedded-gles" into DEPENDS, will that make sure the libs I later add to IMAGE_INSTALL are -gles'y? |
| 11:55.11 | ant_work | eFfeM_work: s/many recipes/many versions of same recipe/ |
| 11:55.13 | eFfeM_work | btw i also have some concerns with inc files, i feel people sometimes change the inc file but at best see if all versions build and at worst only check if it fixes their version and do not care about the other versions |
| 11:55.34 | eFfeM_work | ant_work: agree |
| 11:55.52 | eFfeM_work | and actually u-boot is also somewhat of a mess |
| 11:55.58 | ant_work | atm there is a bit of 'anarchy' :) |
| 11:56.20 | eFfeM_work | yes |
| 11:56.49 | ant_work | heh /linux and /u-boot will be nightmares... |
| 11:57.43 | ant_work | btw pruning 2.4 kernels I saw a 'triton' machine. Seems almost unmaintained. |
| 11:57.56 | *** join/#oe grund (~grund@64.244.156.164) |
| 11:58.01 | ant_work | I did resist and did not move it's recipes to obsolete |
| 11:58.03 | ant_work | but |
| 11:58.04 | eFfeM_work | (actually checked u-boot, it is not that bad 9apart from omap3, omap3beagleboard, omap3pandora versions (that i would expect to be mergeable) and a very big u-boot_git recipe |
| 11:58.45 | eFfeM_work | one of the things I would like to get on the agenda is clearly identifying owners/maintainers for every machine and distro |
| 11:58.55 | ant_work | well, u-boot git is 'refugium peccatorum' :) |
| 11:59.04 | eFfeM_work | and preferably move the orphaned ones to obsolete or unsupported or so |
| 11:59.25 | eFfeM_work | i know, i fear I added my share to u-boot git |
| 12:00.06 | ant_work | I for myelf added some lines to it too |
| 12:00.52 | ant_work | he.. the Zaurus had a single git revision working |
| 12:02.59 | ant_work | anyway, the flood of omap3 recipes will not end up quickly |
| 12:03.22 | ant_work | I see in the kernel ML there are still 'fixes' for 2.6.37 |
| 12:03.48 | eFfeM_work | nope, omap people are good in creating recipes, but not too god at removing the old ones |
| 12:03.56 | ant_work | let's hope by then someone will remove all after 2.6.32 |
| 12:04.12 | ant_work | ^_^ |
| 12:04.36 | eFfeM_work | actually every time I see the ti dir I am also wondering who knows what the difference is between all those variants |
| 12:07.05 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
| 12:12.43 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
| 12:13.01 | *** join/#oe rob_w (~bob@pD95EB46E.dip.t-dialin.net) |
| 12:13.48 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 12:13.48 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 12:24.08 | *** join/#oe JaMa (~martin@161-24.13.24.78.awnet.cz) |
| 12:25.02 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 12:25.19 | *** part/#oe mawillia (~mikew@rrcs-24-39-249-130.nys.biz.rr.com) |
| 12:31.07 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 12:31.24 | *** join/#oe Jay7 (jay@93-81-1-158.broadband.corbina.ru) |
| 12:50.47 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
| 12:54.14 | *** join/#oe rednul_ (~rednul@host-174-45-250-246.bln-mt.client.bresnan.net) |
| 12:58.47 | hrw | eFfeM_work: probably few TI guys do |
| 13:00.42 | eFfeM_work | hrw guess so, but imho the idea of recipes in oe is that they are usable for others; guess it would be nice to know what is the purpose of different versions of a recipe (in general, this does not only apply to ti) |
| 13:01.23 | eFfeM_work | sometimes this is due to license changes, sometimes footprint, sometimes quality, but in most cases it is unknown |
| 13:04.12 | *** join/#oe kevinsc (~a0214685@nat/ti/x-vlolrjftjvldrxby) |
| 13:04.27 | *** join/#oe methril_work (~methril@201.35.65.90) |
| 13:06.44 | XorA | plays hunt the TI guy |
| 13:07.25 | *** join/#oe rschus (~rschus@241.163.71-86.rev.gaoland.net) |
| 13:07.47 | ynezz | XorA: score? |
| 13:08.04 | XorA | 200 grots to the person who nails koen :-) |
| 13:08.36 | *** join/#oe kevinsc1 (~a0214685@nat/ti/x-yqmaubbuvxsiwbjb) |
| 13:09.44 | ynezz | eFfeM_work: can you give me some "ti" example, say from the recipe/linux/ ? I'm just currious |
| 13:14.52 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 13:19.21 | eFfeM_work | ynezz: there are 14 recipes of ti-xdctools in the ti dir, no idea what the difference is between those |
| 13:19.58 | eFfeM_work | also kernel has some omap variants but these are for different boards or maybe they have use (never peeked into it) |
| 13:20.38 | ynezz | ah lol at that ti dir |
| 13:20.39 | eFfeM_work | XorA: maybe ibot will nail him if you lart him |
| 13:21.24 | XorA | misses his Nine Inch Nails gun from quake :-) |
| 13:23.29 | eFfeM_work | XorA: tried to nail koen, ended up with a trauma surgeon :p : http://www.lmgtfy.com/?q=nail+koen&l=1 |
| 13:27.14 | *** join/#oe sge (~username@62.240.71.4) |
| 13:29.09 | *** join/#oe Tartarus (trini@pixelshelf.com) |
| 13:44.52 | *** join/#oe etrunko (~edulima@201.82.27.51) |
| 13:50.44 | *** join/#oe grund (~grund@host65-17-84-58.birch.net) |
| 13:53.31 | *** join/#oe kerim (~kerim@81.214.22.138) |
| 13:57.22 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 13:57.56 | *** join/#oe cargoudel (80afff09@gateway/web/freenode/ip.128.175.255.9) |
| 14:00.57 | cargoudel | good morning .... i managed to get openjdk build for an armv4 ... and the biggest thing i can suggest is use gcc-4.4.4 because 4.4.2 is only the first version of gcc to support eabi on armv4 but in my experience building a lot of packages for oe and gentoo with each version 4.4.4 is much more stable and bug free ..... so In angstrom it defaults to 4.4.2 for armv4 ... bump that to 4.4.4 and things will go a lot easier |
| 14:07.08 | mckoan | maybe could appear a silly question but what is the purpose of qt4-tools-sdk package ? |
| 14:07.36 | mckoan | and how it works ? |
| 14:08.54 | zecke | mckoan: it is a SDK package. So it is used inside the SDK (e.g. meta-toolchain-qt) |
| 14:09.36 | zecke | mckoan: it contains the Qt tools used when building. E.g. qmake (to create a makefile), rcc (to convert files into a .c file with pathnames), moc (to preprocess files and create c++ code)... |
| 14:09.52 | kergoth_ | the *sdk classes are just regular classes with altered prefixes to the sdk root, iirc. crosssdk == cross + sdk prefix |
| 14:10.06 | mckoan | zecke: do you mean it is a meta-toolchain-qt dependency? |
| 14:10.18 | mckoan | looking into meta-toolchain-qt.bb |
| 14:10.39 | kergoth_ | zecke: http://git.openembedded.org/cgit.cgi/bitbake/commit/?id=606fa1fd97cbd47a6a7ebdc7a2e6aa93a8f65cf5 - this seem sane to you? |
| 14:10.57 | zecke | mckoan: indirectly yes, you will find it in task-*qt*-host.bb |
| 14:11.33 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 14:11.34 | mckoan | zecke: meta-toolchain-qt doesn't exist |
| 14:11.45 | mckoan | zecke: do you mean meta-toolchain-qte ? |
| 14:12.16 | zecke | mckoan: qte for master, -qt exists in a branch |
| 14:13.35 | mckoan | what do I get with meta-toolchain-qt ? an environment to install everywhere ? |
| 14:15.03 | kergoth_ | its an sdk. use it to build things outside of OE |
| 14:15.20 | zecke | mckoan: please check the usermanual |
| 14:15.47 | zecke | mckoan: there is a section on meta-toolchain-qte, how it is build, how the result is used |
| 14:17.35 | *** join/#oe CMoH (~cipi@95.76.71.81) |
| 14:17.35 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 14:20.11 | JDuke127 | hello , i tried to compile a sample clutter app but i got this error on pkg-config : http://pastebin.com/urnXvEGA , someone know how to fix that problem ? |
| 14:20.59 | JaMa | JDuke127: mesa should provide gl |
| 14:21.24 | JDuke127 | but i m using omap3 |
| 14:21.28 | JDuke127 | omap3 has mesa ? |
| 14:21.36 | JDuke127 | igepv2 card |
| 14:21.47 | mckoan | zecke: I missed it, thx |
| 14:21.56 | *** join/#oe sge (~username@62.240.71.4) |
| 14:22.40 | JDuke127 | hmm |
| 14:22.46 | JDuke127 | seems like it has mesa |
| 14:22.48 | *** join/#oe rob_w (~bob@pD95EB46E.dip.t-dialin.net) |
| 14:22.49 | JDuke127 | very interesting |
| 14:26.29 | mckoan | zecke: I missed it because my paper printed version is too old :-D |
| 14:26.40 | JDuke127 | JaMa , i did opkg-target install mesa |
| 14:26.50 | JDuke127 | JaMa , but it still didnt success and failed |
| 14:27.30 | JDuke127 | i got same error |
| 14:27.31 | JDuke127 | Package gl was not found in the pkg-config search path. |
| 14:27.31 | JaMa | no idea what's opkg-target |
| 14:27.44 | JDuke127 | its meta-toolchain |
| 14:28.44 | zecke | JDuke127: can you type which pkg-config? |
| 14:30.38 | *** join/#oe kgilmer (~kgilmer@firebug.buglabs.net) |
| 14:30.48 | JDuke127 | zecke , it gaves "/home/kadirbasol/OE/sdk/usr/local/angstrom/arm/bin/pkg-config" , correct path of meta-toolchain |
| 14:30.57 | JDuke127 | maybe i ve some lack of libraries ? |
| 14:31.19 | JDuke127 | without meta-toolchain i got this |
| 14:31.23 | JDuke127 | from devshell |
| 14:31.55 | JDuke127 | http://pastebin.com/n5PTXsFt |
| 14:32.00 | JDuke127 | this is from devshell |
| 14:32.06 | JDuke127 | from meta-toolchain when i do it |
| 14:32.11 | JDuke127 | i got this |
| 14:32.11 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
| 14:32.56 | JDuke127 | http://pastebin.com/KRM0GSiK |
| 14:33.05 | JDuke127 | this one is from meta-toolchain |
| 14:33.12 | JDuke127 | so why meta-toolchain suck |
| 14:33.18 | JDuke127 | i need more libraries ? |
| 14:36.24 | *** join/#oe klaas__ (~chatzilla@d54C07440.access.telenet.be) |
| 14:43.40 | kergoth_ | wow, making referencing nonexistent variables an error is showing all sorts of bugs :) |
| 14:43.46 | kergoth_ | fixes a copule |
| 14:44.42 | *** join/#oe kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 14:44.59 | kergoth_ | its exposing many variable renames from classes which weren't done in all recipes |
| 14:45.00 | kergoth_ | heh |
| 14:45.05 | kergoth_ | well, not many, but some |
| 14:50.11 | *** join/#oe aloisiojr (~aloisio@186.212.114.106) |
| 14:51.35 | *** join/#oe angelox_123 (~Angelo@201-93-218-37.dsl.telesp.net.br) |
| 14:52.44 | *** join/#oe koobe_ (~koobe@dsl-trebrasgw2-fe4df900-31.dhcp.inet.fi) |
| 14:55.24 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 14:55.25 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
| 14:59.05 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 15:00.16 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |
| 15:01.02 | CIA-68 | 03Marco Cavallini <m.cavallini@koansoftware.com> 07org.openembedded.dev * r1d91da33cd 10openembedded.git/conf/distro/include/kaeilos-2010.inc: kaeilos-2010.inc: unset DISTRO_FEED_CONFIGS for kaeilos |
| 15:03.26 | *** join/#oe kevinsc (~a0214685@nat/ti/x-cchtbswcppgabmfr) |
| 15:10.39 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 15:12.52 | CIA-68 | 03Paul Menzel <paulepanter@users.sourceforge.net> 07master * rf58a5d59b7 10openembedded.git/recipes/openmoko-3rdparty/mokosuite2_git.bb: |
| 15:12.52 | CIA-68 | mokosuite2: Add `libfakekey` and `vala-native` to DEPENDS. |
| 15:12.52 | CIA-68 | During the latest bumps of `SRCREV` I guess it was forgotten to add some dependencies. |
| 15:12.52 | CIA-68 | `libfakekey` is needed for a successful configure and without `vala-native` `valac` is not found on a clean and minimal build system. |
| 15:12.53 | CIA-68 | Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> |
| 15:12.53 | CIA-68 | Acked-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 15:13.03 | CIA-68 | 03Paul Menzel <paulepanter@users.sourceforge.net> 07master * r0f83f5f36e 10openembedded.git/recipes/freesmartphone/msmcommd_git.bb: |
| 15:13.03 | CIA-68 | msmcommd_git: Add `libfsotransport` to `DEPENDS`. |
| 15:13.03 | CIA-68 | Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> |
| 15:13.03 | CIA-68 | Acked-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 15:49.47 | *** join/#oe kgilmer (~kgilmer@firebug.buglabs.net) |
| 15:58.24 | *** join/#oe klaas__ (~chatzilla@d54C07440.access.telenet.be) |
| 15:59.52 | *** join/#oe rob_w (~bob@pD95EB46E.dip.t-dialin.net) |
| 16:03.41 | *** join/#oe kevinsc (~a0214685@nat/ti/x-hxfjerpdajimumde) |
| 16:32.55 | *** join/#oe kergoth__ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 16:36.42 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 16:42.00 | *** join/#oe eFfeM (~frans@j200125.upc-j.chello.nl) |
| 16:42.20 | *** join/#oe woglinde (~heinold@g225072001.adsl.alicedsl.de) |
| 16:42.51 | *** join/#oe pH5 (~ph5@e178199038.adsl.alicedsl.de) |
| 16:46.39 | *** join/#oe piroko (~jeremy@pohl.ececs.uc.edu) |
| 16:46.52 | *** part/#oe piroko (~jeremy@pohl.ececs.uc.edu) |
| 16:51.28 | *** join/#oe dijenerate (~dijenerat@64.210.44.37) |
| 16:58.47 | *** join/#oe woglinde (~heinold@g225147020.adsl.alicedsl.de) |
| 17:10.20 | woglinde | hm llvm 2.8 released |
| 17:11.40 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 17:19.40 | foobaz | Is there a way to spead up the bitbake command? What's with the 0 to 100% bitbake files? |
| 17:19.45 | foobaz | speed* |
| 17:19.55 | woglinde | ????? |
| 17:20.15 | woglinde | you can help improve bitbake so its parsing stuff parallel |
| 17:20.36 | *** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 17:21.49 | *** join/#oe rob_w (~bob@pD95EB46E.dip.t-dialin.net) |
| 17:22.57 | foobaz | woglinde, what is that 0 to 100% file stuff is does everytime you run bitbake? Seems like it takes a while. |
| 17:23.58 | woglinde | only the first parsing |
| 17:24.02 | woglinde | the second is faster |
| 17:24.55 | foobaz | Also where are my SVN source files placed? I notice the S variable that most _svn.bb files have. I'm just doing a quick do_compile, but I'm not sure where main.cpp is placed. I tried ${WORKDIR} and ${S} but neither work. Kind of confused. |
| 17:24.59 | foobaz | http://pastebin.com/MMn9icdh |
| 17:25.35 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r26bba2c633 10openembedded.git/recipes/matchbox-keyboard/files/ (2 files): |
| 17:25.35 | CIA-68 | matchbox-keyboard : moved unused files to obsolete dir |
| 17:25.35 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 17:25.35 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * re85268535b 10openembedded.git/recipes/tar/files/ (configure.patch m4.patch): |
| 17:25.36 | CIA-68 | tar : moved unused files to obsolete dir |
| 17:25.36 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 17:25.37 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * rf12a78922c 10openembedded.git/recipes/tcpdump/files/fix-paths.patch: |
| 17:25.37 | CIA-68 | tcpdump : moved unused files to obsolete dir |
| 17:25.38 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 17:25.38 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * re2d2f6959c 10openembedded.git/recipes/tor/tor-0.1.1.26/openssl.patch: |
| 17:25.39 | CIA-68 | tor : moved unused files to obsolete dir |
| 17:25.40 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 17:25.40 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r9aedaeda16 10openembedded.git/recipes/tslib/tslib/multievent.patch: |
| 17:25.41 | CIA-68 | tslib : moved unused files to obsolete dir |
| 17:25.41 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 17:25.42 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * rc8a76d4962 10openembedded.git/recipes/uclibc/files/ (armeb-kernel-stat.h.patch kernel-key-t-ipc.h.patch): |
| 17:25.43 | CIA-68 | uclibc : moved unused files to obsolete dir |
| 17:25.43 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 17:25.46 | woglinde | svn checksout the stuff under archivedir/svn/projectname |
| 17:25.57 | woglinde | and makes a tar.gz-file of it |
| 17:25.59 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r05ac7e7ead 10openembedded.git/recipes/matchbox2/files/glib-2.8-backport.patch: |
| 17:25.59 | CIA-68 | matchbox2 : moved unused files to obsolete dir |
| 17:25.59 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 17:26.06 | woglinde | which it than extract to S |
| 17:26.07 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * ra83a9bf8a4 10openembedded.git/recipes/matchbox-wm/matchbox-wm/kbdconfig_keylaunch_simpad.patch: |
| 17:26.07 | CIA-68 | matchbox-wm : moved unused files to obsolete dir |
| 17:26.07 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 17:26.43 | foobaz | How would that look in my do_compile stage then if I want main.cpp (It's in trunk by itself in the repository). |
| 17:27.32 | eFfeM | foobaz, guess this will speed things up drastically: http://www.dell.com/us/business/p/poweredge-r910/pd?~ck=anav |
| 17:28.12 | *** join/#oe w|zzy (~quassel@220-245-95-7.static.tpgi.com.au) |
| 17:28.27 | *** join/#oe kgilmer (~kgilmer@firebug.buglabs.net) |
| 17:28.38 | *** join/#oe woglinde_ (~heinold@g225145255.adsl.alicedsl.de) |
| 17:28.46 | foobaz | woglinde: also I turned off the tarball checkout. |
| 17:28.56 | foobaz | unless you mean something else |
| 17:30.40 | foobaz | oh I see |
| 17:30.54 | foobaz | So do I have to do something in like do_fetch to uncompress them someplace? |
| 17:32.00 | kergoth_ | foobaz: the archive is uncompressed in the unpack task.. that's what its for. |
| 17:32.23 | kergoth_ | its likely a dir in ${S} of the name of the last component of your svn path, e.g. projectname or trunk |
| 17:32.30 | kergoth_ | er, a dir in WORKDIR |
| 17:32.47 | kergoth_ | just bitbake -e yourrecipe |grep \^WORKDIR= |
| 17:32.49 | kergoth_ | and look in there. |
| 17:45.46 | *** join/#oe cargoudel (80043e65@gateway/web/freenode/ip.128.4.62.101) |
| 17:46.47 | *** join/#oe anarsoul (~anarsoul@212.98.176.195) |
| 17:47.29 | cargoudel | this may seem like a really stupid question once you done compiling for angstrom ... how to you do install the opkgs to a mounted sdcard .. i have all my ipkg just sitting here ready to go |
| 17:50.08 | eFfeM | cargoudel: make an image (e.g. console-image) and extract teh tar file on your sd card |
| 17:50.49 | *** join/#oe kevinsc1 (~a0214685@nat/ti/x-bdfntbhuuemjnvlg) |
| 17:59.41 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 18:00.09 | foobaz | kergoth_: odd. Yeah I see '...build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/walker-svn-r1/' as the working directory. In it is temp trunk and walker but there's no main.cpp file. In in the SVN though (I can see if I do a fresh checkout). |
| 18:00.22 | kergoth | like i just said |
| 18:00.26 | kergoth | what's the final component ofthe svn path? |
| 18:00.28 | kergoth | clearly its trunk |
| 18:00.35 | kergoth | so ${WORKDIR}/trunk is where the sources are |
| 18:00.43 | kergoth | so set S = "${WORKDIR}/trunk" int he recipe |
| 18:01.03 | foobaz | oh. I'll try that. Thanks |
| 18:01.12 | kergoth | np |
| 18:06.37 | *** join/#oe oneshel (~jim@c-98-216-198-0.hsd1.nh.comcast.net) |
| 18:08.06 | khem | kergoth: should kernel-modules appear in RDEPENDS to get included in the final image ? |
| 18:08.40 | kergoth | if you want *all* modules, but its unlikely you do, more likely task-base will intelligently pull in the modules you need based on the capabilities in the features variables |
| 18:08.42 | kergoth | shrugs |
| 18:09.26 | *** join/#oe etrunko (~edulima@201.82.27.51) |
| 18:09.29 | khem | kergoth: hmmm I end up with 0 modules that seems wrong |
| 18:09.45 | khem | kergoth: it worked few days ago |
| 18:09.55 | kergoth | dunno |
| 18:10.04 | kergoth | doesn't watch individual oe recipe commits very closely |
| 18:10.28 | foobaz | kergoth: http://pastebin.com/fdU1Caqf still can't find it. I wonder why it's not unpacking main.cpp |
| 18:10.53 | kergoth | well, where is your main.cpp in your svn? |
| 18:10.56 | kergoth | this isn't an oe problem |
| 18:11.02 | kergoth | it checks out the svn path you gave it |
| 18:11.08 | kergoth | and you're looking in that checkout |
| 18:11.34 | foobaz | It's in trunk. |
| 18:12.03 | foobaz | I deleted my checkout and if I do a fresh checkout I get a folder with trunk,branches,tags and in trunk is main.cpp |
| 18:13.29 | khem | kergoth: hmmm I am using minimal-image which RDEPENDS on task-boot |
| 18:13.34 | khem | but not on task-base |
| 18:15.54 | kergoth | that'd explain it |
| 18:16.21 | kergoth | foobaz: i'd suggest removing the tarball it created from your svn in DL_DIR, then bitbake -c clean yourrecipe, then try baking it again. |
| 18:16.37 | kergoth | rm downloads/*wmich* |
| 18:16.39 | kergoth | or whatever |
| 18:17.00 | *** join/#oe mnabil (~mnabil@41.234.71.188) |
| 18:17.43 | khem | kergoth: task-base DEPENDS on task-boot |
| 18:17.50 | kergoth | yep, it does |
| 18:18.19 | khem | kergoth: so I think the minimal-image bypasses the module inclusion logic |
| 18:18.24 | kergoth | it does, yes |
| 18:18.30 | khem | hmmm |
| 18:18.44 | kergoth | were you using that image a few days ago when it worked? :) |
| 18:18.56 | khem | yes but I shove in modules |
| 18:19.01 | khem | now that I remember |
| 18:19.03 | kergoth | ah |
| 18:19.31 | khem | I keep improving my local.conf for clutter |
| 18:19.56 | khem | if one uses udev then modules are needed I think |
| 18:20.05 | khem | few of them |
| 18:20.34 | khem | so it seems console-image is the next smallest image |
| 18:20.52 | khem | thats like 4000 tasks |
| 18:21.12 | cargoudel | Why does bitbake base-image build X11 and gnome stuff? Does it have to do with my distron settings? |
| 18:21.56 | kergoth | khem: its that many even for a distro other than angstrom? its largely driven by the DISTRO_FEATURES, so if it has less features, it would build less |
| 18:22.10 | kergoth | course we still have some leakage, things like bluez pulling in x and crap, or whatever |
| 18:22.16 | kergoth | those need to be fixed period |
| 18:22.35 | kergoth | we need to take the time to sit down and review the .dot files from bitbake -g in some of these |
| 18:22.46 | kergoth | figure out exactly where things we don't want are coming from, and fix them, on a case by case basis |
| 18:22.53 | kergoth | this is how i found the gtk+-native / cross thing |
| 18:23.18 | woglinde_ | re |
| 18:23.24 | khem | nods |
| 18:24.00 | kergoth | OT, but if anyone else is using osx and is tired of colloquy being buggy as hell, Textual is lovely |
| 18:24.25 | khem | kergoth: I use colloquy |
| 18:24.32 | khem | never tried textual |
| 18:24.50 | kergoth | colloquy has this bug where it randomly stops updating the channel displays, and you ahve to reload the style to fix it |
| 18:24.55 | kergoth | the bug is 4 years old in their bts |
| 18:24.57 | kergoth | :( |
| 18:25.27 | khem | kergoth: looks promising |
| 18:26.19 | kergoth | seems very simple, yet has the nice features that are above text ones like irssi (e.g. growl notification) |
| 18:26.38 | khem | kergoth: yeah I was about to ask about growl integration |
| 18:27.11 | foobaz | kergoth: nah didn't fix it. heh if I uncompress the tar.gz myself after removing it and calling bitbake again the main.cpp isn't even in there. Thanks for your help. I'll have to look around for the answer later. |
| 18:27.46 | kergoth | foobaz: weird. |
| 18:28.02 | khem | foobaz: check if the repo was checked out correctly |
| 18:28.10 | foobaz | how? |
| 18:28.22 | foobaz | if I run a checkout from the command line it works fine |
| 18:28.32 | khem | see under your download dir |
| 18:28.52 | khem | foobaz: what commandline and how do u put it in .vv |
| 18:28.53 | khem | .bb |
| 18:28.57 | khem | pastebin it |
| 18:29.27 | khem | kergoth: you can use quassel on mac too |
| 18:29.30 | khem | if u use it |
| 18:29.37 | khem | it works on mac and windoze |
| 18:29.42 | khem | along with ln |
| 18:29.44 | khem | lnx |
| 18:29.57 | foobaz | I did up there. I gtg. |
| 18:30.10 | khem | ok bye |
| 18:30.32 | CIA-68 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r3408a82d7f 10openembedded.git/recipes/freesmartphone/cornucopia.inc: cornucopia: bump SRCREV again for new vala really compatible versions |
| 18:30.37 | khem | kergoth: its default IRC client on kubuntu thats how I got introduced to it |
| 18:31.34 | kergoth | huh, thanks for the pointer, might try that on windows rather than the silverex xchat builds |
| 18:34.11 | *** join/#oe florian (~fuchs@sign-4d091b6c.pool.mediaWays.net) |
| 18:34.12 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 18:35.52 | *** join/#oe woglinde (~heinold@f052065147.adsl.alicedsl.de) |
| 18:36.05 | khem | hmm xchat on windows is not feee |
| 18:36.15 | kergoth_ | google for silverex xchat |
| 18:36.21 | kergoth_ | old builds unfortunately |
| 18:37.20 | *** join/#oe JaMa (~martin@161-24.13.24.78.awnet.cz) |
| 18:38.15 | *** join/#oe koobe__ (~koobe@dsl-trebrasgw2-fe4df900-31.dhcp.inet.fi) |
| 18:41.51 | cargoudel | whats the quickest way to disable all X from from angstrom |
| 18:42.38 | woglinde | <PROTECTED> |
| 18:42.50 | woglinde | seems to stand in the topic |
| 18:46.26 | Jay7 | kergoth_: kvirc have builds for windows and linux at least :) |
| 18:49.44 | cargoudel | sorry about that ... forgot about the separation between oe and the distros |
| 19:01.23 | woglinde | ~lart 150mb gcc-svn.tar |
| 19:01.23 | ibot | does a little 'renice 20 -u 150mb gcc-svn.tar' |
| 19:01.57 | woglinde | why the hell its downloaidng the 150mb instead of makeing the tar from the svn dir |
| 19:05.43 | *** join/#oe kerim (~kerim@81.214.22.138) |
| 19:07.31 | *** join/#oe dos11 (~dos@etd156.neoplus.adsl.tpnet.pl) |
| 19:07.31 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
| 19:07.51 | woglinde | kergoth is there some way to tell bitbake to use the svn instead of downloading the tar ball? |
| 19:08.08 | kergoth | empty CVS_TARBALL_STASH or whatever, probably |
| 19:08.12 | kergoth | shrugs |
| 19:09.08 | woglinde | ah thanks |
| 19:11.39 | kergoth | damnit, i forgot to write up a proposal to split up classes/ and email the list |
| 19:11.42 | kergoth | mutters |
| 19:13.07 | *** part/#oe kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 19:13.44 | woglinde | hrms |
| 19:14.25 | khem | woglinde: use bitbake master |
| 19:14.42 | woglinde | khem I do |
| 19:14.47 | woglinde | and it dont works |
| 19:14.52 | khem | woglinde: it now strips all SCM crap before making tar |
| 19:15.04 | khem | woglinde: update like today ? |
| 19:15.07 | woglinde | khem cool |
| 19:15.09 | woglinde | khem yes |
| 19:15.13 | kergoth_ | course teh filename is the same, so it'll still download the massive one from teh mirrors.. |
| 19:15.22 | woglinde | still tries to download |
| 19:15.23 | khem | ah yes |
| 19:15.29 | khem | mirrors need updates |
| 19:15.42 | woglinde | so what now? |
| 19:16.04 | woglinde | can someone remove it? |
| 19:16.14 | khem | woglinde: which mirror are you hitting |
| 19:16.24 | woglinde | <PROTECTED> |
| 19:16.38 | khem | cbrake can help removing it on source.openembedded.org |
| 19:16.39 | CIA-68 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r1288cce0db 10openembedded.git/recipes/openmoko-3rdparty/mokowm_git.bb: |
| 19:16.39 | CIA-68 | mokowm: add libfakekey to DEPENDS |
| 19:16.39 | CIA-68 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 19:16.43 | khem | woglinde: ask koen |
| 19:17.09 | woglinde | hm I will fool with /etc/hosts |
| 19:17.16 | khem | ok so it builds fine with libtool 2.2.6b yippie |
| 19:17.24 | khem | now lets flip the switch |
| 19:18.07 | khem | woglinde: you can disable mirrors too |
| 19:18.11 | woglinde | hm which switch? |
| 19:18.25 | khem | woglinde: I am working on libtool 2.4 upgrade |
| 19:18.30 | woglinde | khem yes |
| 19:18.33 | khem | so added a variable to select |
| 19:18.39 | khem | which libtool to use |
| 19:18.39 | woglinde | I know |
| 19:18.40 | Crofton | khem, any changes over the past week that would impact sysv shared mem |
| 19:18.42 | Crofton | gr_vmcircbuf_sysv_shm: shmat (2): Invalid argument |
| 19:18.55 | Crofton | I just started seeing this in gnuradio ... |
| 19:19.15 | khem | Crofton: hmmm compiler changed |
| 19:19.26 | khem | Crofton: were you using gcc 4.5 |
| 19:19.39 | woglinde | is testing llvm2.8 |
| 19:19.49 | khem | woglinde: llvm2.8 is impressive |
| 19:19.51 | Crofton | yes |
| 19:19.57 | Crofton | angstrom 2010 |
| 19:20.30 | khem | Crofton: ok, did you rebuild everything |
| 19:21.01 | woglinde | let see if openjdk runs in qemu |
| 19:21.14 | Crofton | I think so .... |
| 19:21.54 | Crofton | I am thinking I shoud try again |
| 19:22.25 | khem | Crofton: you might run it under strace |
| 19:22.33 | khem | and see whats being passed to shmat |
| 19:22.34 | Crofton | k |
| 19:22.43 | khem | Crofton: whats your glibc ver |
| 19:23.02 | Crofton | eglibc |
| 19:23.10 | Crofton | see angstrom-2010.x |
| 19:23.51 | khem | 2.10.1 |
| 19:24.02 | khem | Crofton: I would ask you to use eglibc |
| 19:24.12 | Crofton | it does |
| 19:24.55 | Crofton | eglilbc-2.11-r14.7 |
| 19:25.15 | khem | ok thats what you are using ? |
| 19:26.24 | *** join/#oe hansdampf (~moritz@212.77.182.8) |
| 19:32.01 | Crofton|work | yes |
| 19:32.45 | kelvie_ | How have other people dealt with kernel-arch not dealing with converting ARCH=i386 to ARCH=x86 for more recent kernels? |
| 19:33.04 | kelvie_ | Or does this not get tested often? It's still broken in kernel-arch.bbclass |
| 19:33.34 | khem | kelvie_: how old is your oe snapshot |
| 19:33.54 | khem | Crofton|work: hmm I think we need to debug the issue |
| 19:34.03 | kelvie_ | khem: Freshly pulled |
| 19:34.44 | kelvie_ | khem: Or has this been fixed in another branch? I pulled from the main repo, and am on master |
| 19:35.02 | khem | kelvie_: if its not on master other might not have it |
| 19:35.14 | khem | kelvie_: what are u building |
| 19:35.18 | kelvie_ | khem: Yeah, the most recent commit to that file is from you |
| 19:35.27 | kelvie_ | khem: An external kernel module |
| 19:35.28 | eFfeM | kelvie_: if there is a bug, please author a patch and send it to the mailing list |
| 19:35.41 | kelvie_ | eFfeM: yeah, I'm trying to find out the best way to do this |
| 19:35.54 | kelvie_ | the arch/ directory in the kernel has changed from 2.6.22 to 2.6.23 |
| 19:35.58 | kelvie_ | Should I do a version check? |
| 19:36.14 | kelvie_ | Or just ls arch/ inside kernel-arch? |
| 19:36.46 | kelvie_ | Anyways, kernel.bbclass tries to look in arch/$ARCH/include/ to copy to staging |
| 19:36.54 | kelvie_ | which is wrong, because arch/i386/ does not exist anymore |
| 19:37.01 | kelvie_ | And thus no include files for my kernel module |
| 19:37.15 | kelvie_ | At least for include/asm |
| 19:37.41 | khem | kelvie_: if you specify ARCH=x86 then map_kernel_arch should return same back |
| 19:37.56 | kelvie_ | khem: Yeah, but this is i386 |
| 19:38.01 | woglinde | kelvie search for x86 and see your failure |
| 19:38.24 | kelvie_ | So I should not use ARCH=i386? |
| 19:38.53 | kelvie_ | TARGET_ARCH, tha tis |
| 19:39.21 | khem | kelvie_: well we support kernels where both i386 and x86 have to be consideref |
| 19:39.39 | woglinde | hm the old kernel recipe should die |
| 19:39.41 | woglinde | *g* |
| 19:39.43 | khem | kelvie_: pass correct ARCH in the external build |
| 19:39.48 | kelvie_ | khem: We have to add some type of check to kernel-arch, yeah |
| 19:39.49 | khem | for module |
| 19:40.01 | kelvie_ | And map i386 to x86 for kernels later than 2.6.22 |
| 19:40.08 | kelvie_ | As well as x86_64; that would break as well |
| 19:40.36 | kelvie_ | woglinde: Is there a newer one? |
| 19:40.41 | woglinde | o.O |
| 19:40.52 | khem | kelvie_: yes |
| 19:41.54 | woglinde | thas in my kernel.bbclass |
| 19:41.57 | woglinde | http://pastebin.com/jj2X6NtZ |
| 19:42.00 | *** join/#oe toi (~toi@d54C2AA76.access.telenet.be) |
| 19:42.03 | woglinde | and deals with x86 |
| 19:42.34 | kelvie_ | woglinde: yeah, I'm doing that now as well |
| 19:42.41 | kelvie_ | It's just a workaround, though |
| 19:42.47 | *** join/#oe cbrake_ (~cbrake_@oh-69-34-21-229.sta.embarqhsd.net) |
| 19:42.53 | khem | kelvie_: try to use get_kernelversion |
| 19:42.58 | khem | and set it accordingly |
| 19:42.59 | *** part/#oe cbrake_ (~cbrake_@oh-69-34-21-229.sta.embarqhsd.net) |
| 19:43.15 | kelvie_ | khem: We have to require linux-kernel-base first though |
| 19:43.16 | kelvie_ | Is that fine? |
| 19:43.25 | khem | yes |
| 19:43.42 | kelvie_ | khem: Wouldn't a more flexible solution be to just ls the arch/ directory? |
| 19:43.53 | kelvie_ | Or is the unpacked sources not available at that time? |
| 19:44.13 | khem | look inside get_kernelversion |
| 19:44.20 | khem | it peeks into sources |
| 19:44.26 | kelvie_ | khem: Ah, okay. |
| 19:44.32 | kelvie_ | I shall peek in myself as well, then :( |
| 19:44.34 | kelvie_ | :) |
| 19:45.09 | khem | try to use that and if it works post a patch for kernel-arch.bbclass |
| 19:45.15 | kelvie_ | khem: Yep, will do that. |
| 19:45.23 | *** join/#oe cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net) |
| 19:53.40 | Crofton|work | khem, I need to remember my sysv shared mem |
| 19:57.43 | ynezz | hm, there's something fishy with the bitbake, removed all references to initscripts in tmp, removed even the tmp/cache, but after that if I run bitbake image, the initscripts package isn't build |
| 19:58.00 | ynezz | even if I do bitbake initscripts it's not build |
| 19:58.23 | woglinde | use -v and -DDD to see whats going on |
| 20:00.22 | Crofton|work | khem, this is the call that fails |
| 20:00.30 | Crofton|work | if (shmat (shmid_guard, first_copy, SHM_RDONLY) == (void *) -1){ |
| 20:06.03 | ynezz | woglinde: http://pastebin.com/R8fmDZL6 |
| 20:06.11 | ynezz | woglinde: I'm not clever from it either |
| 20:06.14 | ynezz | :) |
| 20:06.19 | eFfeM | is there an easy way to weed out old directories from a work tree (apart from nuking the whole tree); with old directories I mean e.g. a r10 version if there is also an r11 work dir |
| 20:06.30 | ynezz | woglinde: it just grep of initscripts debug_log |
| 20:07.06 | ynezz | s/it/its/ |
| 20:08.03 | woglinde | Unknown package 'initscripts'. |
| 20:08.17 | ynezz | I see that also |
| 20:08.28 | ynezz | but it finds before |
| 20:08.36 | ynezz | if I bump PR, it will work |
| 20:09.24 | ynezz | DEBUG: sorted providers for initscripts are: ['/media/data/devel/oe/ts72xx.git/openembedded/recipes/initscripts/initscripts_1.0.bb'] |
| 20:09.42 | ynezz | so what? :) |
| 20:09.57 | ynezz | ynezz@ntbk:/media/data/devel/oe/ts72xx.git/tmp$ find . -name initscripts -print |
| 20:09.57 | ynezz | ./deploy/glibc/sources/GPL/initscripts |
| 20:10.37 | ynezz | should be nothing there, I've purged everything |
| 20:11.57 | ynezz | as I said before, purged tmp/cache also, so I wonder what could I do more to trigger building of that package |
| 20:12.52 | kergoth | ynezz: your find catches files named initscripts, not files with initscripts in it. did you remove the stamps in tmp/stamps? |
| 20:13.29 | ynezz | running grep now |
| 20:13.48 | ynezz | ynezz@ntbk:/media/data/devel/oe/ts72xx.git/tmp$ grep initscripts stamps/ -R |
| 20:13.49 | ynezz | ynezz@ntbk:/media/data/devel/oe/ts72xx.git/tmp$ |
| 20:13.52 | kergoth | i don't see why you wouldn't just bitbake -c clean initscripts |
| 20:13.56 | kergoth | grep is going to do absolutely nothing |
| 20:13.58 | kergoth | stamps are empty files |
| 20:14.03 | kergoth | find tmp/stamps -name \*initscripts\* |
| 20:14.05 | ynezz | oh |
| 20:14.17 | kergoth | if a stamp exists for a given task, bitbake knows its completed it, so it wont run it again |
| 20:14.18 | ynezz | I've tried -c clean first |
| 20:14.22 | ynezz | then -c distclean |
| 20:14.26 | ynezz | then remove ipk |
| 20:14.32 | ynezz | then remove tmp/cache |
| 20:14.35 | ynezz | then asked here :) |
| 20:15.11 | ynezz | ah stamps is full of it |
| 20:15.22 | kergoth | clean removes stamps |
| 20:15.25 | kergoth | so don't know what to tell you |
| 20:15.33 | kergoth | also the purpose of stamps is in the manuals.. |
| 20:17.15 | kergoth | grumbles |
| 20:18.01 | ynezz | sorry and thanks |
| 20:18.16 | kergoth | np |
| 20:18.30 | ynezz | If I remember it correctly, stamps used to be in the different place |
| 20:18.35 | kergoth | nope |
| 20:18.49 | kergoth | well, its always been in tmp/stamps/ |
| 20:18.53 | kergoth | used to be at toplevel though |
| 20:19.01 | kergoth | rather than deeper there by arch |
| 20:19.05 | kergoth | or whatever |
| 20:19.09 | *** join/#oe Martin-B (~martin@pool-105-67-198-89.dbd-ipconnect.net) |
| 20:19.26 | ynezz | hm, fixed, easy peasy :p |
| 20:19.53 | ynezz | jesus, not |
| 20:20.19 | ynezz | it finaly build the package, but image can't find it |
| 20:21.28 | woglinde | hm seems they didnt build llvm2.8 for arm |
| 20:23.10 | *** join/#oe kergoth__ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 20:31.57 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * rc2a9e77a93 10openembedded.git/recipes/mythtv/ (4 files): |
| 20:31.57 | CIA-68 | mythtv: fixed LICENSE added a few other headers for mythplugins and myththemes |
| 20:31.57 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 20:33.10 | woglinde | hm damn they dont support shared libs anymore in a right way |
| 20:36.56 | CIA-68 | 03Marco Cavallini <m.cavallini@koansoftware.com> 07org.openembedded.dev * rc53d253363 10openembedded.git/conf/distro/include/kaeilos-2010.inc: kaeilos-2010.inc: replaced typo, sorry |
| 20:41.42 | kelvie_ | When does python code get evaluated in bb/bbclass files? |
| 20:41.47 | kelvie_ | On evaluation of the variable? |
| 20:42.02 | kergoth | that depends on what you mean by python code |
| 20:42.06 | kergoth | inline snippets of the ${@} sort? |
| 20:42.10 | kelvie_ | kergoth: yeah |
| 20:42.16 | kergoth | all variables are expanded when used |
| 20:42.25 | kergoth | epxansion is when all ${} are evaluated, including the python ones |
| 20:42.30 | kergoth | so yes, on evaluation |
| 20:42.37 | kergoth | unless someone uses := in an assignment, this is immediate eval |
| 20:42.40 | kergoth | same behavior as gmake |
| 20:42.48 | filip | khem: you there by any chance? |
| 20:42.50 | filip | khem: [10:04] < filip> khem: I lost my link yesterday. Do you think I should add http://pastebin.com/KiMhk4hx to (e)glibc recipes? |
| 20:42.50 | kelvie_ | kergoth: gotcha, thanks |
| 20:42.53 | kergoth | np |
| 20:45.52 | filip | um, how should I prepare a list of packages to be build for a distro's online package repository? |
| 20:46.02 | filip | just some kind of a metapackage with many dependencies? |
| 20:46.41 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * rd0e2850d99 10openembedded.git/recipes/streamripper/streamripper_1.64.6.bb: |
| 20:46.41 | CIA-68 | Fix RDEPENDS |
| 20:46.41 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 20:46.44 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * rae44179e69 10openembedded.git/recipes/streamripper/streamripper_1.61.3.bb: |
| 20:46.44 | CIA-68 | streamripper_1.61.3.bb: removed |
| 20:46.44 | CIA-68 | had cve's and was not properly configured and missing depends; |
| 20:46.44 | CIA-68 | latest version is already in OE for quite a while. |
| 20:46.45 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 20:46.45 | CIA-68 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r1be6794639 10openembedded.git/recipes/perl/libtree-simple-perl_1.18.bb: |
| 20:46.46 | CIA-68 | Fix RDEPENDS |
| 20:46.46 | CIA-68 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 20:50.20 | *** join/#oe timtimred (~meh@85.210.129.53) |
| 20:52.03 | khem | filip: I am currently testing this patch will push it shortl |
| 20:52.38 | filip | khem: ah thanks :) |
| 20:52.53 | filip | khem: do you know perhaps the answer to my question above? |
| 20:53.36 | khem | filip: look into recipes/tasks and recipes/images |
| 20:53.59 | filip | I can handle images, I am just wondering about feeds |
| 20:54.51 | filip | for example there is this ugly script: contrib/angstrom/build-feeds.sh, should I do the equivalent? |
| 20:55.20 | filip | as in specify a list of packages in the shell file executing bitbake? |
| 20:55.22 | khem | yes thats a starting point |
| 20:56.05 | filip | on the other side, ./recipes/tasks/task-openmoko-feed.bb looks like a waaay nicer method |
| 20:56.30 | filip | could I create recipes/tasks/task-jlime-feed.bb? |
| 20:57.57 | *** join/#oe ant_ (~andrea@host71-190-dynamic.60-82-r.retail.telecomitalia.it) |
| 21:02.27 | kergoth | can't believe i never tried this out before.. these helpers for datasmart are handy, and rather pleasant to look at |
| 21:02.40 | kergoth | d.setVars(foo=5, bar=4) |
| 21:02.49 | kergoth | d.setVarFlags("foo", func=True, task=True) |
| 21:03.00 | kergoth | (these don't exist yet, just playing with them) |
| 21:04.57 | kergoth | made my signature unit tests much much more readable |
| 21:06.56 | CIA-68 | 03Khem Raj <raj.khem@gmail.com> 07master * r5bcd2b8a09 10openembedded.git/recipes/eglibc/ (3 files in 2 dirs): |
| 21:06.56 | CIA-68 | eglibc_2.12.bb/eglibc_svn.bb: Fix build on ARMv4 with EABI |
| 21:06.56 | CIA-68 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 21:09.51 | eFfeM | calling it a day, cya |
| 21:10.03 | khem | eFfeM: bye |
| 21:10.28 | *** join/#oe jduke128 (51d6168a@gateway/web/freenode/ip.81.214.22.138) |
| 21:10.51 | jduke128 | hi all , i cant do make on clutter , i ve found the problems some of them but |
| 21:12.09 | jduke128 | when i try to run "make" i got error as shown on pastebin : http://pastebin.com/dhbDQgSV , why compiling error occurs ? |
| 21:12.49 | *** join/#oe yann (~dwitch@nan92-1-81-57-214-146.fbx.proxad.net) |
| 21:13.10 | woglinde | jduke128 it is using pixman from your host |
| 21:13.14 | woglinde | which is wrong |
| 21:13.27 | jduke128 | i know but , there seems it has bug inside |
| 21:13.39 | jduke128 | my configs seems fine ? how can i change it to use my target |
| 21:13.42 | jduke128 | pixman |
| 21:13.45 | jduke128 | not host |
| 21:13.50 | jduke128 | how to fix ? |
| 21:14.17 | woglinde | /usr/lib/libpixman-1.la |
| 21:14.38 | woglinde | look at the m4 macros inside clutter |
| 21:14.45 | woglinde | maybee they are using some hardcoded stuff |
| 21:14.56 | woglinde | or clutter is missing a dep on pixman |
| 21:15.10 | *** join/#oe angelox_123 (~Angelo@201-93-218-37.dsl.telesp.net.br) |
| 21:15.29 | jduke128 | aclocal.m4 |
| 21:15.33 | jduke128 | this |
| 21:16.06 | jduke128 | there is no libpixman there |
| 21:16.37 | ant_ | florian: ping |
| 21:18.01 | florian | ant_: pong |
| 21:18.07 | ant_ | hello |
| 21:18.24 | ant_ | we have an issue with gpe-image |
| 21:18.34 | ant_ | in particular, gpe-package |
| 21:18.35 | angelox_123 | what ? |
| 21:19.21 | ant_ | still depends on 'libipkg' |
| 21:19.48 | angelox_123 | hum,IIRC i had the same issue,but i forget say... |
| 21:19.59 | ant_ | just changing with opkg won't work. there are hardcoded calls to ipkg iirc |
| 21:20.14 | angelox_123 | yes,i tried it too =d |
| 21:20.17 | angelox_123 | yes,i tried it too =D* |
| 21:20.18 | ant_ | angelox_123, hi, yes, I've seen you had same issue |
| 21:21.29 | filip | khem: I believe that the ARMv4 problem applies to glibc as well |
| 21:22.12 | khem | filip: it does |
| 21:22.21 | khem | filip: use eglibc |
| 21:22.45 | filip | khem: I am, but just saying... ;) |
| 21:22.55 | khem | eglibc is a superset of glibc + a lot more for embedded systems |
| 21:23.38 | khem | filip: we dont have recipes for glibc 2.12 yet |
| 21:23.45 | khem | so its not a problem in OE right now |
| 21:24.25 | filip | ah :) |
| 21:26.26 | ant_ | florian: this is compile log with deps on opkg: http://pastebin.ca/1955875 |
| 21:26.37 | khem | I am hopin that in future users will only use eglibc |
| 21:26.43 | khem | as it fits the OE bill better |
| 21:26.53 | *** part/#oe hoj (~jfaith@75-147-191-205-Washington.hfc.comcastbusiness.net) |
| 21:28.41 | filip | hm |
| 21:29.04 | florian | ant_: i'll take a look |
| 21:29.09 | filip | btw, is there a way I could use dpkg instead of ipkg as a package manager on the target system? |
| 21:30.23 | filip | hm, it seems like mamona does that |
| 21:30.43 | ant_ | khem, today Gentoo got libtool-2.2.10 stable for x86 |
| 21:34.30 | ant_ | and for HPPA |
| 21:46.21 | khem | filip: you can should not be that hard |
| 21:46.38 | khem | ant_: 2.2 is cakewalk |
| 21:46.47 | khem | ant_: 2.4 is a different beast |
| 21:52.01 | *** join/#oe pcacjr (~pcacjr@187.78.35.66) |
| 21:52.01 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 22:02.41 | *** join/#oe pcacjr (~pcacjr@187.78.20.8) |
| 22:02.41 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 22:08.44 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
| 22:13.19 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 22:33.00 | *** join/#oe angelox_123 (~Angelo@201-93-218-37.dsl.telesp.net.br) |
| 22:34.27 | CIA-68 | 03Andreas Oberritter <obi@opendreambox.org> 07master * r0741f11dcb 10openembedded.git/recipes/matroska/ (5 files): |
| 22:34.27 | CIA-68 | lib{ebml,matroska}-1.0.0: intitial recipes |
| 22:34.27 | CIA-68 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
| 22:34.27 | CIA-68 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 22:34.27 | CIA-68 | 03Petr Å tetiar <ynezz@true.cz> 07master * r4085252bf8 10openembedded.git/recipes/initscripts/ (files/save-rtc-uclibc.sh initscripts_1.0.bb): |
| 22:34.27 | CIA-68 | init-scripts: fix save-rtc error with date formatting on uclibc |
| 22:34.28 | CIA-68 | uClibc's date does support only SUSv3 strptime[1], so the date command in |
| 22:34.28 | CIA-68 | save-rtc.sh fails with 'date: invalid date '%2m%2d%2H%2M2010'. |
| 22:34.29 | CIA-68 | 1. http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html |
| 22:34.29 | CIA-68 | Signed-off-by: Petr Å tetiar <ynezz@true.cz> |
| 22:34.30 | CIA-68 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 22:34.31 | CIA-68 | 03Petr Å tetiar <ynezz@true.cz> 07master * rf2e95d221a 10openembedded.git/recipes/busybox/ (busybox.inc files/hwclock.sh): (log message trimmed) |
| 22:34.50 | CIA-68 | busybox: add posibility to specify correct rtc device for hwclock init script |
| 22:34.50 | CIA-68 | With this patch it's now possible to specify rtc device using HWCLOCKDEVICE |
| 22:34.50 | CIA-68 | variable in /etc/default/hwclock and the system time is then set using correct |
| 22:34.51 | CIA-68 | device and vice versa. It's wise to have such functionality, beacuse there're |
| 22:34.51 | CIA-68 | SBCs with more then one rtc device, for example ts72xx. |
| 22:34.52 | CIA-68 | Signed-off-by: Petr Å tetiar <ynezz@true.cz> |
| 22:34.52 | CIA-68 | 03Paul Menzel <paulepanter@users.sourceforge.net> 07master * r3b5ff5ac90 10openembedded.git/recipes/python/ (4 files in 2 dirs): (log message trimmed) |
| 22:34.53 | CIA-68 | python-{native}-2.6.5: Fix parallel build. |
| 22:35.07 | CIA-68 | Randomly the build failed for me with the following error message. |
| 22:35.07 | CIA-68 | libpython2.6.so: undefined reference to `_PyParser_Grammar' |
| 22:35.07 | CIA-68 | The applied patch in [5] tried to fix this problem, but it turns out that this also was due to a possible race. This is already known in OpenOffice too [3]. |
| 22:35.08 | CIA-68 | R. David Murray (dmalcolm) <dmalcolm@fedoraproject.org> fixed this in Fedora [1] and I applied his patch. |
| 22:35.08 | CIA-68 | I reported this issue upstream [4] and this will only be fixed in Python 2.7, so we have to keep this patch for Python 2.6. |
| 22:35.08 | CIA-68 | 03Andreas Oberritter <obi@opendreambox.org> 07master * r0f4f8f3e76 10openembedded.git/recipes/libsigc++-1.2/ (3 files in 2 dirs): |
| 22:35.09 | CIA-68 | libsigc++-1.2: fix installation |
| 22:35.09 | CIA-68 | * install complains about method_slot.h, which is mentioned twice |
| 22:35.10 | CIA-68 | inside Makefile.am. |
| 22:35.10 | CIA-68 | * v2: Added header to patch. |
| 22:35.11 | CIA-68 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
| 22:35.11 | CIA-68 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 22:35.12 | CIA-68 | 03Andreas Oberritter <obi@opendreambox.org> 07master * rf65559a539 10openembedded.git/recipes/mumudvb/ (mumudvb.inc mumudvb_1.6.bb): |
| 22:35.12 | CIA-68 | (56 lines omitted) |
| 22:35.42 | *** part/#oe angelox_123 (~Angelo@201-93-218-37.dsl.telesp.net.br) |
| 22:35.58 | CIA-68 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r912a51db1b 10openembedded.git/conf/machine/include/zaurus-2.6.inc: zaurus-2.6.inc: evaluate here kernel bootlogo size |
| 22:36.00 | CIA-68 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r99c8541b71 10openembedded.git/recipes/linux/linux.inc: |
| 22:36.00 | CIA-68 | linux.inc: allow for more bootlogo customization. |
| 22:36.00 | CIA-68 | * kernel recipes can add a custom-sized bootlogo in SRC_URI |
| 22:36.00 | CIA-68 | * e.g. SRC_URI = "file://${LOGO_SIZE}/logo_linux_clut224.ppm.bz2" |
| 22:36.01 | CIA-68 | * before including/requiring linux.inc. |
| 22:36.01 | CIA-68 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r08cd165298 10openembedded.git/recipes/linux/linux-kexecboot.inc: linux-kexecboot.inc: don't define LOGO_SIZE here (machine-specific) |
| 22:41.27 | khem | kergoth: what do u think of this patch http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=0ee7a9e6bdce1f3094e831b9db83087fff1dad17 |
| 22:42.08 | kergoth | khem looks good |
| 22:42.19 | khem | we should merge it |
| 22:42.20 | kergoth | that'll get rid of the odd behavior where the local file doesn't exist and it doesnt' know why |
| 22:42.31 | khem | yep |
| 22:43.11 | kergoth | poky's bitbake is quite a ways apart from upstream now due to the work RP is doing on the signatures and per task archiving and all |
| 22:43.14 | kergoth | but that one we can grab just fine |
| 22:43.27 | khem | righto |
| 22:44.03 | kergoth | man, testing to catch pstage relocation issues takes a looooong time |
| 22:45.46 | khem | http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=e3d7890cace71b0a57d2530bf615a58dcb46d96f |
| 22:45.49 | khem | is interesting too |
| 22:45.55 | khem | we should consider that one |
| 22:46.01 | kergoth | indeed |
| 22:47.20 | khem | once I am thru libtool 2.4 |
| 22:47.38 | khem | I will try to separate gcc libraries/runtime |
| 22:47.50 | kergoth | adds poky as a remote to bitbake to see if its possible to apply the commits directly with a -p path strip |
| 22:48.15 | khem | kergoth: can you do that |
| 22:48.20 | khem | I always thought |
| 22:48.35 | kergoth | aha |
| 22:48.35 | kergoth | i got it |
| 22:48.37 | khem | poky still uses packages/ instead of recipes/ |
| 22:48.39 | kergoth | check this out |
| 22:48.44 | khem | cool |
| 22:48.56 | kergoth | git remote add poky git://git.pokylinux.org/poky |
| 22:48.58 | kergoth | git fetch poky |
| 22:49.03 | kergoth | git format-patch --stdout -1 0ee7a9e6bdce1f3094e831b9db83087fff1dad17 | git am -p 2 |
| 22:49.09 | kergoth | the -p 2 strips off the extra bitbake/ path |
| 22:49.12 | kergoth | so it applies perfectly |
| 22:49.18 | khem | hmmm |
| 22:49.21 | khem | and then git am ? |
| 22:49.30 | khem | I always tried cherry-pick |
| 22:49.30 | kergoth | points at the above | git am -p 2 |
| 22:49.38 | kergoth | i dont think cherry pick can do it |
| 22:49.39 | khem | ugh linewrap |
| 22:49.40 | kergoth | no -p thing |
| 22:49.42 | khem | right |
| 22:49.44 | kergoth | but format-patch + am will |
| 22:49.51 | kergoth | this should be handy.. |
| 22:49.56 | khem | cool stuff |
| 22:50.03 | khem | indeed |
| 22:50.18 | kergoth | then add -s to the am to sign off since i'm applying it, and adjust the commit message to kill bitbake/, and ready to push |
| 22:50.34 | khem | may be we should add a wiki page "How to add patches from poky" |
| 22:50.45 | kergoth | yeah, that could be useful |
| 22:51.06 | Crofton|work | I still need to buy a plane ticket for ELCE and OEDEM |
| 22:51.08 | khem | git am --sign-off ? |
| 22:51.09 | kergoth | hmm, the one concern i have with that patch |
| 22:51.23 | kergoth | it doesn't re-raise the fetcherror it got, it raises its own |
| 22:51.31 | kergoth | which loses any details the fetcher might have provided |
| 22:51.38 | kergoth | yeah, -s is --sign-off |
| 22:52.09 | kergoth | well, this is an improvement, can revisit it |
| 22:52.29 | CIA-68 | 03Joshua Lock <josh@linux.intel.com> 07master * r12066bf508 10bitbake.git/lib/bb/fetch/__init__.py: (log message trimmed) |
| 22:52.29 | CIA-68 | fetch: if mirror fetching fails, ensure exception is raised |
| 22:52.29 | CIA-68 | We catch any exception raised by the fetchers go() method and attempt to work |
| 22:52.29 | CIA-68 | around it by trying any (post) mirrors which are configured. However, should |
| 22:52.29 | CIA-68 | the mirrors fail the exception is lost and the fetch is assumed to have |
| 22:52.30 | CIA-68 | completed successfully. |
| 22:52.31 | CIA-68 | Instead, save the exception and if the local file does not exist after trying |
| 22:52.38 | kergoth | heh. |
| 22:53.02 | kergoth | i don't know why i didn't think about using am to adjust paths before |
| 22:53.19 | kergoth | that was much easier than any other method i've used |
| 22:54.01 | khem | yeah I thought it preserved the fetcher exception |
| 22:55.01 | Crofton|work | NOTE: Gettext required but not in DEPENDS for file /home/balister/oe/tmp/work/armv7a-angstrom-linux-gnueabi/gcc-4.5-r12.1+svnr164562/gcc-4.5/intl/configure.ac. |
| 22:55.01 | Crofton|work | Missing inherit gettext? |
| 22:55.06 | Crofton|work | just went by ... |
| 22:55.46 | khem | Crofton|work: for now ignore those |
| 22:56.10 | khem | gcc uses its own version of gettext |
| 22:56.15 | kergoth | ick |
| 22:56.26 | khem | which is fine |
| 22:56.54 | khem | hmmm thats target gcc |
| 22:57.01 | Crofton|work | k |
| 22:57.06 | Crofton|work | I just saw it fklash by |
| 22:57.14 | khem | k |
| 22:58.53 | khem | kergoth: hmm I reckon same strip level wont work for oe metadata |
| 22:59.17 | kergoth | not directly, no, due to the difference in layout |
| 22:59.28 | khem | right |
| 22:59.29 | kergoth | hmmm. |
| 22:59.36 | *** part/#oe grund (~grund@host65-17-84-58.birch.net) |
| 22:59.43 | kergoth | wonders if there'd be some way to apply into a subdir, or combine a subtree merge with an am or something.. |
| 23:00.07 | kergoth | wait, this is promising |
| 23:00.17 | kergoth | yep, thatll do it |
| 23:00.25 | kergoth | khem: -p + --directory= |
| 23:00.40 | kergoth | e.g. -p 5 --directory=recipes/foo |
| 23:00.46 | kergoth | strips off, then prepends |
| 23:00.48 | kergoth | then applies |
| 23:00.50 | kergoth | to am |
| 23:00.53 | khem | perfect |
| 23:00.59 | kergoth | this is assuming of course the recipe filenames are the same |
| 23:01.02 | kergoth | not much we could do about that :) |
| 23:01.07 | kergoth | other than manually applying |
| 23:01.11 | kergoth | but its something |
| 23:01.32 | khem | yeah |
| 23:02.27 | kergoth | <3 git |
| 23:04.08 | kergoth | khem: note that you could also manually apply the changes, like whent eh recipe files are different |
| 23:04.13 | kergoth | and then commit using ci -s -c <hash> |
| 23:04.20 | kergoth | to use the log, author, etc from the original commit |
| 23:05.07 | khem | correct |
| 23:05.17 | khem | I do that many times on ill formed patches sent to OE |
| 23:05.27 | CIA-68 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r57c890552b 10openembedded.git/conf/machine/include/zaurus-2.6.inc: zaurus-2.6.inc: remove superfluous MACHINE_KERNEL_VERSION = "2.6" |
| 23:05.31 | CIA-68 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * rac99aeee69 10openembedded.git/conf/machine/ (include/simpad-2.6.inc simpad.conf): simpad: merge simpad-2.6.inc in simpad.conf |
| 23:05.31 | CIA-68 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * ra934499cee 10openembedded.git/conf/machine/include/ (collie-2.4.inc simpad-2.4.inc): collie+simpad: remove unused -2.4 inc files |
| 23:05.31 | CIA-68 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * raa376b7ded 10openembedded.git/conf/machine/simpad.conf: simpad.conf: remove superfluous MACHINE_KERNEL_VERSION ?= "2.6" |
| 23:06.35 | kergoth | ah, good :) |
| 23:06.43 | kergoth | maybe we need a git tips and tricks section of the oe wiki |
| 23:06.49 | kergoth | with both general and specific to oe |
| 23:07.10 | grg | kergoth, yes please. My git-fu is poor. |
| 23:07.37 | khem | kergoth: we do have one |
| 23:07.46 | kergoth | we should enhance it, then :) |
| 23:07.48 | kergoth | adds to todo |
| 23:07.52 | khem | right |
| 23:08.15 | khem | http://wiki.openembedded.net/index.php/GitPhraseBook |
| 23:13.52 | khem | git am -s -p 3 --directory=recipes <mbox> is what we need for recipes |
| 23:14.33 | *** join/#oe angelox_123 (~Angelo@201-93-218-37.dsl.telesp.net.br) |
| 23:14.55 | *** part/#oe angelox_123 (~Angelo@201-93-218-37.dsl.telesp.net.br) |
| 23:15.16 | khem | kergoth: LIC_FILES_CHKSUM is this something pokyness |
| 23:15.25 | kergoth | think so |
| 23:15.30 | kergoth | never heard of it |
| 23:15.32 | khem | hmmm |
| 23:16.23 | khem | http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=2ccd2e67c5768e59316b086fa70fef837eecb53a |
| 23:17.05 | khem | kergoth: seems a good think though |
| 23:18.09 | tharvey | anyone using x86_64 host? seems that python-psyco does not support this - looking for alternatives to help speed up build time |
| 23:18.31 | Tartarus | correct, nope |
| 23:18.35 | khem | yes psyco is only for x86 |
| 23:19.12 | tharvey | read that psyco is no longer in devel and there is pypy perhaps to replace it? also read that python built for 32bit compat mode would support psyco - not sure what that entails and if its worth it |
| 23:19.46 | kergoth | i'd certainly be interested to see how pypy or unladen swallow or something would do |
| 23:19.47 | khem | how much do we gain with psyco in 32bit |
| 23:20.16 | Tartarus | feels like a lot |
| 23:20.33 | tharvey | khem, thats a good question - all I know is I moved to a 8GB ram 64bit system with SSD and my build times are about as bad as they were on my old 2GB 32bit laptop |
| 23:21.01 | khem | tharvey: use ramfs |
| 23:21.06 | tharvey | seems like I'm sitting often waiting for cache |
| 23:21.22 | tharvey | khem, ramfs for what though? TMPDIR is way too big |
| 23:21.36 | khem | tharvey: with rm_work |
| 23:21.41 | khem | it peeks around 8G |
| 23:21.46 | tharvey | rm_work? |
| 23:21.51 | khem | and then you can spit deploy to disk |
| 23:22.15 | tharvey | reads rm_work.bbclass |
| 23:22.17 | kergoth | btw, http://grab.by/6JX6 is Textual. don't miss colloquy at all |
| 23:22.24 | kergoth | tharvey: it wipes WORKDIR when the build is done for the recipe |
| 23:22.32 | khem | tharvey: rm_work is class if you inherit it then it deleted the build dir after generatin packages |
| 23:22.39 | grg | bitbake world with rm_work for mipsel is about 50GB |
| 23:23.37 | tharvey | interesting... so ramfs + rm_work gives you quite a speedup? |
| 23:23.44 | khem | kergoth: I am gonna try it tonight |
| 23:23.47 | khem | when I reach hoe |
| 23:23.50 | khem | home |
| 23:23.57 | khem | *thick fingers* |
| 23:24.27 | khem | tharvey: yes it should |
| 23:24.46 | khem | tharvey: 1:30 mins for a x11-image from scratch |
| 23:24.58 | khem | that was 1:30 hrs or 90mins |
| 23:25.14 | khem | tharvey: thats second hand info though |
| 23:25.38 | khem | my machines have 2G of RAM and a poor core2duo |
| 23:26.25 | tharvey | do you perhaps have this config written up anywhere? So you set TMDIR to a ramfs filesystem, and DEPLOY_DIR to a disk filesystem, then inherit rm_work? |
| 23:27.04 | khem | tharvey: add INHERIT += "rm_work" in your local.conf |
| 23:27.12 | khem | that will enable it for your builds |
| 23:28.11 | tharvey | right, but TMPDIR and DEPLOY_DIR point to ramfs and disk based fs respectively and thats all, or other dir tweaks too? |
| 23:32.39 | khem | tharvey: mkdir -p /mnt/tmp |
| 23:33.01 | khem | mount -t ramfs -o size=6000m ramfs /mnt/ram |
| 23:33.28 | khem | I mean mount -t ramfs -o size=6000m ramfs /mnt/tmp |
| 23:34.31 | tharvey | ya, going to give it a spin - thanks for the info! |
| 23:34.50 | khem | tharvey: but if your system crashes or reboots then it will be gone |
| 23:35.29 | tharvey | understood |
| 23:35.32 | khem | tharvey: cool let up know what crazy speedup you get |
| 23:35.45 | tharvey | ya, I'll do a comparison over the next day |
| 23:35.57 | khem | cool |
| 23:36.10 | ant_ | almost one year ago I had three images(console, opie, x11) in 2,5GB after build |
| 23:36.25 | khem | btw. you can emit PSTAGE_DIR into disk too |
| 23:37.16 | ant_ | well, this can be dangerous if you build recipes using package_stagefile_shell iirc |
| 23:40.27 | ant_ | yes, is still there |
| 23:40.29 | ant_ | http://blog.denix.org/2008/09/getting-even-more-dangerous-with-pstage.html |
| 23:41.01 | ant_ | destfile=`echo $srcfile | sed s#${TMPDIR}#${PSTAGE_TMPDIR_STAGE}#` |
| 23:43.20 | Tartarus | hm |
| 23:45.07 | Tartarus | I'm not sure what that's supposed to do now-a-days |
| 23:45.14 | kergoth | yeah, that can't be safely moved out |
| 23:45.15 | Tartarus | pstaging is safe with kernels and uboot |
| 23:45.17 | denix | Tartarus: nobody knows :) |
| 23:45.18 | kergoth | it does what it always did |
| 23:45.36 | tharvey | guess I'll find out tonight |
| 23:45.36 | kergoth | pstage packages are installed relative to TMPDIR |
| 23:45.42 | kergoth | so it needs a path relative from TMPDIR to store in pstage |
| 23:45.55 | kergoth | stagefile puts it into place so that will happen |
| 23:46.05 | denix | still there - can't move deploy outside of TMPDIR w/o breaking pstage... |
| 23:46.07 | kergoth | if where it needs to be is outside of TMPDIR, you're hosed |
| 23:46.17 | kergoth | pstage can't install files outside of its offline root (TMPDIR) |
| 23:46.46 | Tartarus | Oh that's right, that's where I get confused :) |
| 23:46.51 | Tartarus | We do pstaging stored outside of tmpdir |
| 23:46.56 | Tartarus | But deploy inside of tmpdir |
| 23:46.59 | kergoth | it's like you're populating an image, and want busybox installed outside of / |
| 23:47.01 | kergoth | not gonna happen |
| 23:47.03 | kergoth | right |
| 23:47.15 | denix | can deploy be moved out of TMPDIR, but pstage moved back to TMPDIR from deploy? |
| 23:47.21 | Tartarus | And yeah, breaking up the structure of tmpdir is unsafe |
| 23:47.32 | kergoth | iirc DEPLOY_DIR_PSTAGE is fine, just not PSTAGE_DIR |
| 23:47.35 | khem | TMPDIR=/mnt/ram; PSTAGE_DIR=${TMPDIR}/../../scratch/oe/pstage |
| 23:47.38 | Tartarus | pstage can be stored anywhere |
| 23:47.38 | khem | will that work |
| 23:47.38 | kergoth | so moving deploy dir should be fine as of the reorg |
| 23:47.40 | Tartarus | since it's relocatable |
| 23:47.42 | tharvey | what if you built your tmpdir using binds? started off with ramfs with binds for pstage/deploy subdirs to disk fs? |
| 23:48.00 | kergoth | again, as far as i know its safe to move DEPLOY_DIR_PSTAGE since the two locations were split |
| 23:48.05 | Tartarus | it's the whole of deploy that's the problem |
| 23:48.20 | kergoth | right, its the files deployed there that need to go into pstage packages that hose you |
| 23:48.31 | Tartarus | DEPLOY_DIR_PSTAGE is dead :) It's just PSTAGE_DIR |
| 23:49.24 | kergoth | oh, right, it uses an internal location for the other files |
| 23:49.31 | Tartarus | tharvey, tricks like that might be OK |
| 23:49.40 | Tartarus | since the expected structure exists in some form |
| 23:49.46 | kergoth | DEPLOY_DIR_PSTAGE got renamed to PSTAGE_TMPDIR_STAGE, and PSTAGE_DIR has only the packages |
| 23:49.52 | kergoth | always forgets the variable names |
| 23:50.03 | Tartarus | kergoth, yeah |
| 23:50.05 | Tartarus | confusing |
| 23:50.24 | kergoth | a bind mount for deploy would be fine, i expect |
| 23:50.36 | kergoth | not sure about a symlink, might confuse the classes, not sure |
| 23:51.03 | khem | PSTAGE_TMPDIR_STAGE and PSTAGE_DIR whats the difference in simple terms |
| 23:51.05 | kergoth | Tartarus: the confusion is that we have one variable for two purposes |
| 23:51.14 | kergoth | files go both into PSTAGE_DIR and come from PSTAGE_DIR |
| 23:51.17 | kergoth | along the lines of DL_DIR |
| 23:51.20 | kergoth | so DEPLOY is a misnomer |
| 23:51.28 | kergoth | which makes sense, but only if you think about it that way :) |
| 23:52.16 | Tartarus | Errr |
| 23:52.22 | Tartarus | Unless I'm way reading the code wrong |
| 23:52.46 | Tartarus | PSTAGE_TMPDIR_STAGE is "temporary space for mangling a pstage package" |
| 23:53.26 | khem | PSTAGE_TMPDIR_STAGE is when you are building one recipe |
| 23:53.27 | khem | I see |
| 23:53.39 | khem | and the final stage ipks go into PSTAGE_DIR |
| 23:53.44 | kergoth | yeah |
| 23:53.52 | Tartarus | Right |
| 23:53.56 | ant_ | ok, we want to keep those |
| 23:53.58 | khem | so one needs to move PSTAGE_DIR out of ramfs |
| 23:54.01 | Tartarus | PSTAGE_DIR is what you re-use |
| 23:54.11 | Tartarus | PSTAGE_DIR is safe to store /where/ever/ |
| 23:54.18 | khem | that was the whole point |
| 23:54.21 | khem | :) |
| 23:54.22 | khem | thanks |
| 23:54.40 | khem | keep TMPDIR in ramfs |
| 23:54.55 | khem | point PSTAGE_DIR and DEPLOY_DIR to somewher on disk |
| 23:55.05 | Tartarus | Almost |
| 23:55.18 | Tartarus | DEPLOY_DIR isn't safe to set outside of TMPDIR |
| 23:55.24 | Tartarus | So you have to do bind mount games |
| 23:55.39 | khem | why |
| 23:55.54 | Tartarus | That's what the post above is about |
| 23:56.14 | Tartarus | Stuff expects DEPLOY_DIR as a subdir of TMPDIR |
| 23:59.02 | *** join/#oe rednul_ (~rednul@host-174-45-250-246.bln-mt.client.bresnan.net) |
| 23:59.34 | *** join/#oe Guest89987 (~saa@nat/google/x-kwpoqbbkitevmxmf) |
| 23:59.52 | khem | why cant we change that sed'ing |