| 00:05.37 | dj-death | who is using mips64 ? :) |
| 00:06.03 | dj-death | same question for sh5 :) |
| 00:12.01 | khem | dj-death: is there sh5 |
| 00:12.17 | khem | dj-death: and mips64 I expect octeon and xlr folks |
| 00:12.40 | khem | and if we have sample implementation people who are interested will consider OE |
| 00:13.11 | khem | dj-death: and OE for sh is used by reneras |
| 00:13.16 | khem | renesas |
| 00:14.10 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
| 00:14.21 | khem | ka6sox: hi |
| 00:14.33 | ka6sox | hi |
| 00:14.46 | khem | ka6sox: I was trying to revive bugzilla |
| 00:15.00 | khem | somehow I think its apache issue may be |
| 00:15.35 | ka6sox | could be.... |
| 00:15.36 | khem | http://bugzilla.openembedded.org/ shows the list of files which it should have executed the CGI scripts |
| 00:16.43 | ka6sox | okay let me look in a few...just got back...kinda dusty and need a shower. |
| 00:18.33 | khem | ka6sox: sure how was it btw |
| 00:18.38 | khem | and where did you camp |
| 00:18.53 | *** join/#oe andyj (~andy@c-76-28-141-180.hsd1.wa.comcast.net) |
| 00:19.10 | ka6sox | khem, cachuma lake |
| 00:19.25 | ka6sox | it was very nice...fog came in too early IMHO. |
| 00:19.34 | ka6sox | so the viewing was short but sweet |
| 00:22.46 | khem | ka6sox: is it towards solvang ? |
| 00:23.59 | ka6sox | khem, yep |
| 00:24.05 | ka6sox | near there |
| 00:25.02 | ka6sox | khem, I use OE to control my telescope. |
| 00:25.38 | khem | ka6sox: I think I have been there IIRC |
| 00:25.50 | khem | during 2008 summer |
| 00:26.01 | khem | ka6sox: control telescope |
| 00:26.04 | khem | interesting |
| 00:26.38 | ka6sox | yes, it controls the mount and takes the pictures, as well as monitoring weatehr. |
| 00:26.41 | ka6sox | er weather. |
| 00:26.52 | khem | nice |
| 00:27.06 | khem | what processor is in use in there |
| 00:27.39 | ka6sox | IXP425(X3)currently....new is Marvell Kirkwood (single) |
| 00:28.09 | ka6sox | (3 Slugs vs 1 OpenRD client) |
| 00:29.51 | ka6sox | the slug issue was not enough RAM. |
| 00:49.29 | khem | cool |
| 00:59.54 | *** join/#oe janinge (j@ninge.net) |
| 01:00.38 | *** join/#oe Martin-B (~martin@pool-206-66-198-89.dbd-ipconnect.net) |
| 01:04.36 | *** join/#oe fidencio (~fidencio@li113-135.members.linode.com) |
| 01:05.55 | fidencio | A very noob question. I build one package using bitbake. Where's the pakcage, after build |
| 01:05.58 | fidencio | ? |
| 01:07.05 | *** join/#oe arun_ (~arun@unaffiliated/sindian) |
| 01:18.32 | *** join/#oe sorvats (~sorvats@190.230.129.146) |
| 01:22.14 | *** join/#oe aloril (~aloril@87-93-42-101.bb.dnainternet.fi) |
| 01:30.51 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
| 01:46.20 | grg | fidencio[AWAY], have a look in your tmp dir, under "deploy" |
| 01:47.05 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:08.13 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:08.59 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:13.04 | *** join/#oe xxiao_ (~xxiao@70.114.141.218) |
| 02:13.23 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:18.51 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:20.58 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:24.58 | *** join/#oe josef___ (~chatzilla@dslb-188-099-020-227.pools.arcor-ip.net) |
| 02:26.21 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:30.42 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:31.03 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:31.39 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:31.59 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:42.04 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
| 02:49.53 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:57.28 | *** join/#oe angelox_123 (~Angelo@201-95-111-80.dsl.telesp.net.br) |
| 03:32.53 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 03:58.03 | *** join/#oe xobs (~smc@cm28.eta34.maxonline.com.sg) |
| 03:58.11 | *** join/#oe borg__ (~olaf@p548695BA.dip0.t-ipconnect.de) |
| 03:58.22 | *** join/#oe mithro (~tim@unaffiliated/mithro) |
| 04:06.55 | *** join/#oe kerim (~kerim@81.214.22.138) |
| 04:34.43 | *** join/#oe koobe_ (~koobe@dsl-trebrasgw2-fe4df900-31.dhcp.inet.fi) |
| 05:35.06 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 05:38.57 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 05:41.36 | *** join/#oe d_th (~dth@a89-182-92-45.net-htp.de) |
| 05:44.02 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 05:54.03 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 05:59.35 | eFfeM_work | gm |
| 05:59.47 | *** join/#oe akumar (~mm4@122.170.27.202) |
| 06:02.18 | *** join/#oe AvengerMoJo (~alex@222.126.194.154) |
| 06:03.19 | *** join/#oe methril (~methril@189.27.128.236.dynamic.adsl.gvt.net.br) |
| 06:03.28 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 06:24.48 | *** join/#oe vps1 (~vitus@145.253.169.210) |
| 06:25.13 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
| 06:28.39 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
| 06:29.53 | *** join/#oe johncylee (~john@61.57.131.211) |
| 06:39.45 | grg | bitbake -k world failed again. ERROR: fork failed: 12 (Cannot allocate memory) |
| 06:40.49 | *** join/#oe fahad (8bb5d022@gateway/web/freenode/ip.139.181.208.34) |
| 06:40.52 | Unhelpful | interesting, i see a relocatable class, but nothing appears to use it. looks like it's for shuffling libs around and fixing w/ chrpath. the doesn't fix search paths for other resources, though :/ |
| 06:41.04 | Unhelpful | grg: you must build more pylons? ;) |
| 06:41.38 | eFfeM_work | grg: too bad. allocate more swap? |
| 06:41.54 | grg | 6gb ram + 2gb swap not enough? |
| 06:42.00 | eFfeM_work | didn't make too much progress either, our build server is fairly new and seems to have some stability issues |
| 06:42.16 | eFfeM_work | blames Xen |
| 06:42.33 | eFfeM_work | grg, should be, unless there is a mem leak |
| 06:42.42 | Unhelpful | grg: funny, i'm building w/ much less than that, though i'm not building *much*. |
| 06:42.55 | grg | Unhelpful, normal image builds are fine |
| 06:43.41 | eFfeM_work | grg, is this on a specific recipe? and repeatable ? |
| 06:43.50 | Unhelpful | eFfeM_work: -k world :) |
| 06:44.04 | grg | i'll have a poke around... |
| 06:44.12 | eFfeM_work | Unhelpful: you live up your name :-) I knew *that* |
| 06:44.32 | Unhelpful | eFfeM_work: thanks, the jokes i get whenever i'm useful :/ |
| 06:44.49 | eFfeM_work | but the error is given on a task while processing a recipe |
| 06:45.30 | eFfeM_work | it might be something related to a specific recipe |
| 06:46.07 | Unhelpful | or might just happen whenever it runs out if there's a leak :/ |
| 06:46.57 | eFfeM_work | yes, that's why i was asking about reproducability, if it is a specific recipe I could also try a build here (or @home) |
| 06:47.40 | Unhelpful | or he could try building that recipe, maybe it's not in his normal image builds :) |
| 06:47.42 | eFfeM_work | actually due to the server issues I gave up on world for now (although I might kick it off again at my workstation tomorrow as I'll be away for a few days) |
| 06:48.23 | grg | eFfeM_work, Unhelpful. Its reproducable. recipes/farsight/gst-plugins-farsight_0.10.1.bb, do_configure sucks up all the memory rather quickly |
| 06:48.30 | eFfeM_work | but I am now trying a bitbake -c fetchall world, that already gave one issue, plan to continue with -c patchall (assuming it exists) |
| 06:49.16 | eFfeM_work | grg, at least that helps to pinpoint the problem |
| 06:49.31 | grg | yeah, it should be fixable knowing the recipe |
| 06:49.46 | grg | looks at the configure script |
| 06:51.38 | grg | its another 4 year old recipe. |
| 06:51.56 | eFfeM_work | yeah, just saw that too |
| 06:52.04 | eFfeM_work | too many people just creating a recipe and let it rot |
| 06:54.09 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
| 06:56.07 | *** join/#oe cjjnjust (~cjjnjust@2001:da8:100e:4797:223:8bff:fe76:39db) |
| 06:56.19 | eFfeM_work | grg: http://farsight.freedesktop.org/releases/obsolete/gst-plugins-farsight/OBSOLETE |
| 06:56.43 | grg | eFfeM_work, git rm it? |
| 06:56.57 | eFfeM_work | i suggest moving to obsolete |
| 06:57.30 | eFfeM_work | <PROTECTED> |
| 06:57.52 | eFfeM_work | btw: http://farsight.freedesktop.org/releases/obsolete/gst-plugins-farsight/ |
| 06:58.15 | eFfeM_work | and: http://farsight.freedesktop.org/releases/obsolete/farsight/OBSOLETE |
| 06:58.46 | eFfeM_work | so maybe retire all this farsight stuff as the project moved on to farsight2 2 years ago |
| 07:00.29 | *** join/#oe GNUtoo|laptop (~gnutoo@host55-144-dynamic.54-79-r.retail.telecomitalia.it) |
| 07:00.45 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
| 07:01.02 | grg | eFfeM_work, maybe i should just poke Koen to fix the problem? |
| 07:01.38 | eFfeM_work | you can try, i didn't know farsight, but seems like something nice |
| 07:02.49 | *** join/#oe martin_B (~martin@pool-73-65-198-89.dbd-ipconnect.net) |
| 07:02.54 | mckoan | good morning |
| 07:03.00 | grg | hello |
| 07:06.09 | *** join/#oe josh__ (~josh@174-22-233-113.phnx.qwest.net) |
| 07:07.18 | *** join/#oe cyberdeck (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 07:08.32 | *** join/#oe xobs (~smc@cm28.eta34.maxonline.com.sg) |
| 07:08.43 | *** join/#oe Proxyles (~henrik@c-9f93e255.56-4-64736c14.cust.bredbandsbolaget.se) |
| 07:09.08 | *** join/#oe rschus (~rschus@177.163.71-86.rev.gaoland.net) |
| 07:11.02 | *** join/#oe Heinervdm (~thomas@pD9E15D75.dip.t-dialin.net) |
| 07:15.42 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 07:21.53 | hrw | morning |
| 07:23.47 | mckoan | hrw: hi |
| 07:28.29 | *** join/#oe CMoH|office (~cipi@89.238.251.90) |
| 07:30.36 | ericben | hi |
| 07:37.08 | *** join/#oe kristoffer (~kristoffe@c-27dee555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 07:37.13 | eFfeM_work | hi ericben, hrw, mckoan, all |
| 07:37.48 | eFfeM_work | ericben: peeked at your patches, but what I do not understand is why python-modules would depend on python-dev and not on python |
| 07:40.11 | ericben | eFfeM_work: where does python-modules depends on python-dev ? |
| 07:40.28 | *** join/#oe CMoH-office (~cipi@89.238.251.90) |
| 07:40.39 | *** join/#oe dth_ntb (~dth@a89-182-3-2.net-htp.de) |
| 07:40.44 | eFfeM_work | ericben: mistyped, it is rdepends (it is in the inc file where I send a patch for) |
| 07:40.59 | ericben | yes and my patch removes that |
| 07:42.40 | ericben | + it tunes python-distutils to remove unecessary files and it changes the tools used to generate the python-2.6-manifest.inc |
| 07:43.00 | eFfeM_work | ah ok, didn't see the inc file was originally generated |
| 07:43.34 | *** join/#oe fraxinath (~quassel@p4FD664C6.dip.t-dialin.net) |
| 07:43.40 | fraxinath | morning guys |
| 07:44.13 | eFfeM_work | ericben: patch looks fine with me, but afaik mickey is our python wiz |
| 07:44.19 | eFfeM_work | hi fraxinath |
| 07:46.00 | fraxinath | i got a question... has anybody ever tried creating a recipe for aacskeys? i wonder wether i should try to get a native version of that premake utility to run and adapt those lua scripts for oe, or do all the compiling with oe instead |
| 07:46.24 | eFfeM_work | does not have a clue what aacskeys is |
| 07:47.19 | fraxinath | uhm consider it a c++ written tool with premake lua scripts which allow it to compile under windows/visual studio, macosx and linux |
| 07:47.54 | ericben | eFfeM_work: so can you ack this python patch series ? |
| 07:49.13 | eFfeM_work | ericben, looking at them |
| 07:49.22 | ericben | thanks |
| 07:49.36 | eFfeM_work | wrt patch3: we don't want to support static linking (removal of libpython2.6a) |
| 07:51.25 | eFfeM_work | ericben & not too sure whether python-modules should depend on python itself |
| 07:52.16 | ericben | eFfeM_work: for patch3 : yes but it's not a directory where the linker can find the .a and that's installed on the target |
| 07:52.25 | eFfeM_work | true |
| 07:52.47 | ericben | for the depend on python : maybe, I didn't touch to this yet, I just needed to remove the -dev as this was exploding the image size ! |
| 07:54.23 | eFfeM_work | i know had the same issue (actually got quite some messages that other -dev packages were not there when creating the image |
| 07:56.06 | eFfeM_work | ok, will send ack |
| 08:00.15 | eFfeM_work | ericben: acks have been sent |
| 08:02.15 | *** join/#oe ZeeD (~ZeeD@190.187.241.83.in-addr.dgcsystems.net) |
| 08:02.27 | ericben | eFfeM_work: thanks |
| 08:02.32 | eFfeM_work | yw |
| 08:02.47 | ericben | btw, can you try a bitbake gs to check it also fails in your configuration ? |
| 08:03.01 | ericben | I'm finishing a fix for this |
| 08:03.44 | eFfeM_work | actually ideally one would not depend on python-modules but instead depend on only those modules that are really needed |
| 08:03.50 | eFfeM_work | ericben: will try to build grg |
| 08:10.36 | *** join/#oe GarthPS (~quassel@92.102.66.79) |
| 08:13.12 | *** join/#oe florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 08:13.12 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:17.16 | *** join/#oe xobs (~smc@cm234.psi175.maxonline.com.sg) |
| 08:17.55 | *** join/#oe rschus (~rschus@177.163.71-86.rev.gaoland.net) |
| 08:19.05 | florian | good morning |
| 08:21.08 | *** join/#oe johncylee (~john@61.57.131.211) |
| 08:25.23 | eFfeM_work | hi florian |
| 08:38.51 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 08:45.45 | *** join/#oe Proxyles (~henrik@c-9f93e255.56-4-64736c14.cust.bredbandsbolaget.se) |
| 08:53.48 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 09:04.29 | *** join/#oe aloril (~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) |
| 09:09.18 | fraxinath | eFfeM_work, i moved my openembedded work dirs from an arch linux to a ubuntu system and now i get /dream/oe1.6/dm8000/build/tmp/cross/mipsel/libexec/gcc/mipsel-oe-linux/4.4.3/cc1: error while loading shared libraries: libcloog.so.0: cannot open shared object file: No such file or directory |
| 09:09.26 | fraxinath | how do i fix that? |
| 09:10.20 | hrw | do rebuild |
| 09:10.40 | hrw | you changed host system and your host binaries linked to host libraries. |
| 09:10.53 | fraxinath | ayee |
| 09:11.16 | fraxinath | what all do i have to rebuild? all native packages? |
| 09:11.21 | hrw | yes |
| 09:11.32 | fraxinath | is there a command to do exactly that? |
| 09:11.51 | hrw | one command? no. one line of shell? yes |
| 09:12.18 | fraxinath | hehe sorry that's what i meant |
| 09:12.43 | hrw | check tmp/stamps/YOURHOSTARCHDIR/*_do_build and do 'bitbake -cclean + bitbake" on each of them |
| 09:13.05 | fraxinath | okay that's what i thought |
| 09:14.52 | fraxinath | hm there aren't any *build stamps in there |
| 09:16.38 | *** join/#oe sgh (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 09:17.03 | hrw | then other stamps |
| 09:17.15 | hrw | it was a bit of time siince my last OE build |
| 09:19.03 | fraxinath | sure, i used fetch instead |
| 09:28.05 | *** join/#oe xeon-enouf (~xeon-enou@unaffiliated/xeon-enouf) |
| 09:43.11 | *** join/#oe woglinde (~henning@p5DDC3942.dip.t-dialin.net) |
| 09:45.45 | *** join/#oe alx_ (~alx@host249-198-dynamic.4-87-r.retail.telecomitalia.it) |
| 09:46.00 | alx_ | hi all |
| 09:46.16 | alx_ | I'm starting studying oe |
| 09:46.22 | mckoan | hi alx_ |
| 09:46.44 | alx_ | I'm testing oe |
| 09:46.54 | alx_ | compiling x86 images |
| 09:46.55 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
| 09:46.59 | woglinde | hi mackoan |
| 09:46.59 | alx_ | this may sound weird :) |
| 09:47.06 | alx_ | hi mckoan |
| 09:47.21 | woglinde | hm x86 and amd64 target isnt tested tough |
| 09:47.56 | alx_ | well, I may assure that console-image and helloworld-image |
| 09:48.02 | alx_ | compile and works :) |
| 09:48.16 | alx_ | cannot say the same for x11-image |
| 09:48.25 | alx_ | that compiles |
| 09:48.57 | alx_ | but on boot I get a lot of "No space left on device" and even waiting a lot... it doesn't come on a working x11 or console login |
| 09:49.15 | alx_ | (using ext2 images) |
| 09:50.06 | alx_ | that sounded to me like a misconfiguration |
| 09:50.15 | *** join/#oe xeon-enouf (~xeon-enou@unaffiliated/xeon-enouf) |
| 09:50.15 | alx_ | but I've no glue on where to start search |
| 09:50.26 | alx_ | google didn't help me |
| 09:50.27 | alx_ | :( |
| 09:50.57 | alx_ | woglinde, any idea where to search ? |
| 09:52.08 | woglinde | alx hm |
| 09:52.26 | alx_ | now I'm building xorg-image |
| 09:52.50 | alx_ | the problem is that we have a board which is Atom :) |
| 09:52.57 | woglinde | alx |
| 09:53.05 | mckoan | alx_: x86 with x11-image has been broken for ages |
| 09:53.12 | woglinde | you know the resizefs command? |
| 09:53.24 | woglinde | alx make your partition on the atom |
| 09:53.35 | woglinde | dd the oe ext2 image on it |
| 09:53.43 | woglinde | run resizefs |
| 09:53.44 | alx_ | did it already :) |
| 09:53.46 | woglinde | off you go |
| 09:53.56 | woglinde | hm than I am puzzeld |
| 09:54.26 | alx_ | I've an ext2 image of about 2G in size, which 128M are used |
| 09:55.17 | alx_ | mckoan, that isn't good :) so x11-image or xorg-image are either broken ? didn't read that they were broken :( |
| 09:57.33 | alx_ | what I'm trying to do is an image for for embedded x86 :) |
| 09:57.57 | woglinde | alx yes right |
| 09:58.09 | woglinde | but why the hell the resizefs dont works |
| 10:00.18 | *** join/#oe xobs_ (~smc@cm234.psi175.maxonline.com.sg) |
| 10:02.00 | alx_ | woglinde, it works. but when I boot it still says I've no space :) |
| 10:02.28 | woglinde | alx hm on which partition? |
| 10:02.36 | alx_ | if I mount the image thru loop (it's an ext2 image) I see a lot of free space |
| 10:02.47 | alx_ | one single partition |
| 10:03.09 | *** join/#oe blindvt (~bf@85-127-79-21.dynamic.xdsl-line.inode.at) |
| 10:03.22 | alx_ | it just says me I've no free space when I boot it |
| 10:06.21 | *** join/#oe rschus (~rschus@177.163.71-86.rev.gaoland.net) |
| 10:07.23 | fraxinath | hrw: problem persists after having rebuild all native packages |
| 10:09.32 | hrw | fraxinath: all *-cross were part of it? |
| 10:10.46 | fraxinath | hm no the *cross stamps aren't in my host-architecture dir but in my target-architecture dir |
| 10:11.02 | fraxinath | i'll rebuild those too |
| 10:14.31 | alx_ | woglinde, well |
| 10:14.35 | alx_ | xorg-image works :) |
| 10:15.32 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
| 10:16.52 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 10:23.36 | *** join/#oe ynezz (ynezz@ibawizard.net) |
| 10:29.45 | *** join/#oe otavio (~otavio@189.114.111.55) |
| 10:29.45 | *** join/#oe otavio (~otavio@debian/developer/otavio) |
| 10:48.43 | woglinde | re |
| 10:49.01 | woglinde | alx what did you change? |
| 10:52.13 | *** join/#oe xobs (~smc@64.9.156.37) |
| 10:56.36 | alx_ | woglinde, built xorg-image instead of x11-image |
| 10:57.01 | alx_ | I've a python-qt program to run on top of X |
| 10:57.14 | alx_ | in the embedded x86 enviroment :) |
| 10:57.42 | woglinde | yeah python-qt is nice |
| 11:03.09 | *** join/#oe ALoGeNo (~alogeno@unaffiliated/alogeno) |
| 11:03.16 | alx_ | the idea is to have a small distro which starts x and the the python-qt |
| 11:03.25 | alx_ | I think this is something others already did |
| 11:03.32 | alx_ | but I was unable to find them |
| 11:03.42 | alx_ | and I feel like I'm reinventing the wheel |
| 11:05.27 | woglinde | hehe |
| 11:05.48 | woglinde | how do you start X? |
| 11:05.58 | woglinde | gdm/kdm with autologin? |
| 11:06.02 | woglinde | no windowmanager? |
| 11:06.54 | alx_ | that will be next step |
| 11:07.03 | alx_ | I'd think no wm |
| 11:07.25 | alx_ | because it's a full screen single application |
| 11:07.26 | woglinde | hm |
| 11:07.43 | woglinde | but you can have problems with some focus stuff |
| 11:07.51 | alx_ | true |
| 11:08.00 | woglinde | thats why we used blackbox in the end |
| 11:08.03 | woglinde | with our app |
| 11:08.04 | alx_ | now I'm thinking how to solve loss of power |
| 11:08.09 | woglinde | written in java |
| 11:08.23 | alx_ | how do you manage loss of power |
| 11:08.34 | woglinde | loss of power? |
| 11:08.50 | alx_ | like ... ops .. i removed the battery |
| 11:09.13 | woglinde | hm shouldnt happen in the setup we have |
| 11:09.21 | alx_ | that is something that may happens without breaking filesystem :) |
| 11:09.24 | woglinde | but we used ubuntu |
| 11:09.29 | alx_ | I see |
| 11:09.34 | woglinde | and dropped it to the bare deps |
| 11:09.40 | alx_ | our current solution is on ubuntu |
| 11:10.03 | woglinde | because we needed to much java deps which arent in oe |
| 11:10.05 | woglinde | like cxf |
| 11:12.23 | alx_ | I see |
| 11:12.24 | alx_ | got to go |
| 11:12.32 | alx_ | appointment in 30 minutes :) |
| 11:12.34 | alx_ | see later |
| 11:28.36 | *** join/#oe cjjnjust (~cjjnjust@2001:da8:100e:4797:223:8bff:fe76:39db) |
| 11:41.23 | *** join/#oe Jay7x (jay@93-81-3-20.broadband.corbina.ru) |
| 12:14.54 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 12:17.28 | *** join/#oe aditya_1010 (~Aditya@pool-96-241-213-103.washdc.fios.verizon.net) |
| 12:25.38 | *** join/#oe B_Lizzard (~havoc@athedsl-435705.home.otenet.gr) |
| 12:34.38 | *** join/#oe Jin^eLD (~jin@belief.htu.tuwien.ac.at) |
| 12:34.42 | Jin^eLD | hi |
| 12:37.59 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 12:44.30 | Jin^eLD | so, ich schaue mal ob ich mit diesem image den test nachstellen kann |
| 12:44.33 | Jin^eLD | oops wrong window |
| 12:44.34 | Jin^eLD | dammit :) |
| 12:44.41 | woglinde | hihi |
| 12:44.58 | Jin^eLD | BitchX in split mode in a terminal, and I always forget to switch the view :) |
| 12:52.56 | Jin^eLD | hm? |
| 13:00.31 | CIA-68 | 03Sebastian Krzyszkowiak <seba.dos1@gmail.com> 07org.openembedded.dev * r7f20d12652 10openembedded.git/recipes/freesmartphone/cornucopia.inc: |
| 13:00.31 | CIA-68 | cornucopia: bump SRCREV for proximity sensor support on N900 |
| 13:00.31 | CIA-68 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 13:06.55 | *** join/#oe sorvats (~sorvats@190.230.129.146) |
| 13:09.36 | *** join/#oe janinge (j@ninge.net) |
| 13:10.04 | *** join/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl) |
| 13:14.21 | mr_nice | do we have any source mirrors where I can upload a source tarball and use it in a recipe, using the debian mirror feels wrong :) |
| 13:14.32 | *** join/#oe kevinsc (~a0214685@nat/ti/x-ghahdpoxtefbouey) |
| 13:20.03 | woglinde | mr_nice why? |
| 13:20.45 | *** join/#oe etrunko (~edulima@187.75.148.141) |
| 13:23.06 | *** join/#oe kristoffer (~kristoffe@c-27dee555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 13:23.38 | mr_nice | woglinde: I don't know if it is ok to generate network traffic to a debian mirror for a non debian distribution. the debian mirrors ofcourse are very reliable |
| 13:28.07 | ericben | is there a reason for /var/spool being in flash and not in volatile ? |
| 13:28.16 | ericben | in recipe base-files |
| 13:28.59 | *** join/#oe mzs (~michael@scesoc.engsoc.carleton.ca) |
| 13:29.12 | woglinde | ericben better ask on the ml |
| 13:29.29 | ericben | woglinde: ok |
| 13:29.48 | mzs | does anyone have a working build of util-linux-ng they'd be willing to send me the do_install log from? |
| 13:30.21 | mzs | it's failing for me because of multiple files called (literally) ".8" being installed on the same install command line |
| 13:30.22 | *** join/#oe JaMa (~martin@161-24.13.24.78.awnet.cz) |
| 13:31.03 | mzs | also looksl ike tinderbox is down |
| 13:31.08 | ericben | mzs: works fine here, do you have the error message ? this seems to be the manpages |
| 13:31.34 | mzs | ericben: yeah, i posted on friday (http://permalink.gmane.org/gmane.comp.handhelds.openembedded/37058) and it's the setarch / rdev manpage links |
| 13:31.55 | mzs | /home/michael/git/newstix/tmp/sysroots/x86_64-linux/usr/bin/install: will not overwrite just-created `/home/michael/git/newstix/tmp/work/i486-oe-linux/util-linux-ng-2.17-r29.2/image/usr/share/man/man8/.8' with `.8' |
| 13:32.23 | ericben | interesting |
| 13:32.29 | mzs | The command line it's running is .../tmp/sysroots/x86_64-linux/usr/bin/install -c -m 644 ctrlaltdel.8 cytune.8 setarch.8 ldattach.8 tunelp.8 rtcwake.8 pivot_root.8 switch_root.8 .8 linux32.8 linux64.8 i386.8 .8 '.../tmp/work/i486-oe-linux/util-linux-ng-2.17-r29.2/image/usr/share/man/man8' |
| 13:32.33 | ericben | /home/ebenard/OEUKREA/tmp_angstrom/sysroots/i686-linux/usr/bin/install -c -m 644 ctrlaltdel.8 cytune.8 \ |
| 13:32.36 | ericben | setarch.8 ldattach.8 tunelp.8 rtcwake.8 pivot_root.8 switch_root.8 linux32.8 linux64.8 '/home/ebenard/OE\ |
| 13:32.39 | ericben | UKREA/tmp_angstrom/work/armv5te-angstrom-linux-gnueabi/util-linux-ng-2.17-r30.2/image/usr/share/man/man8\ |
| 13:32.46 | ericben | 'I don't have the .8 you have at the end |
| 13:33.04 | ericben | I'm building for arm |
| 13:33.04 | mzs | Yeah. i have a .8 after switch_root and a .8 after linux64 |
| 13:33.09 | woglinde | mzs tinderbox had someplrobels after the debian update |
| 13:33.20 | mzs | woglinde: cool, thanks |
| 13:33.25 | ericben | here .8 avec linux64 but you also have a .8 alone |
| 13:33.30 | mzs | ericben: i'm building for i486 |
| 13:33.42 | woglinde | args some problems |
| 13:34.14 | *** join/#oe etrunko (~edulima@187.75.148.141) |
| 13:36.27 | *** join/#oe vanous (~vanous@194.228.223.3) |
| 13:36.29 | mzs | ericben: I'm using autoconf-native 2.63, automake-native 1.11.1, util-linux-ng 2.17, coreutils-native 8.5 |
| 13:36.38 | mzs | and my build host is running make 3.80 |
| 13:37.32 | ericben | mzs: here autoconf-native 2.65, automake-native 1.11.1 and host has make 3.81 |
| 13:38.05 | mzs | hmm, i wonder if something got tweaked in how make handles blank lines (empty variable expansionss and '\') inside a variable setting |
| 13:40.05 | mzs | wow, make 3.80 is 8 years old! |
| 13:42.09 | woglinde | mzs yeah |
| 13:43.03 | mzs | i wonder if i can get oe to build & use its own make |
| 13:43.15 | mzs | make isn't in the default ASSUME_PROVIDED but it doesn't seem to get built |
| 13:45.47 | *** join/#oe dth_ntb (~dth@a89-182-92-45.net-htp.de) |
| 13:48.10 | mzs | Yeah. it's definitely something that changed in make 3.81. |
| 13:51.59 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 13:53.59 | *** join/#oe pcacjr (~pcacjr@187.59.240.56) |
| 13:54.15 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 13:58.12 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 14:04.12 | *** join/#oe zlt_ (~zlt@li146-250.members.linode.com) |
| 14:12.18 | *** join/#oe kerim (~kerim@81.214.22.138) |
| 14:12.20 | CIA-68 | 03Björn Krombholz <pirobk@gmail.com> 07org.openembedded.dev * r224e984680 10openembedded.git/classes/qt4e.bbclass: (log message trimmed) |
| 14:12.21 | CIA-68 | qt4-embedded: avoid circular dependencies for reciped providing qt4-embedded |
| 14:12.21 | CIA-68 | * qt4e.bbclass did add a dependency on qt4-embedded for recipes |
| 14:12.21 | CIA-68 | providing qt4-embedded. This breaks building of qt4-embedded-gles |
| 14:12.21 | CIA-68 | in 2 ways: |
| 14:12.21 | CIA-68 | 1. PREFERRED_PROVIDER_qt4-embedded = qt4-embedded-gles |
| 14:12.22 | CIA-68 | adds a circular dependency. |
| 14:22.54 | *** join/#oe ALoGeNo (~alogeno@unaffiliated/alogeno) |
| 14:23.21 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 14:28.46 | *** join/#oe pcacjr (~pcacjr@187.59.240.56) |
| 14:28.46 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 14:38.41 | *** join/#oe koobe_ (~koobe@dsl-trebrasgw2-fe4df900-31.dhcp.inet.fi) |
| 14:44.57 | *** join/#oe lisppaste (~lisppaste@common-lisp.net) |
| 14:46.34 | Crofton|work | anyone seen this failure in numpy |
| 14:46.36 | Crofton|work | <PROTECTED> |
| 14:46.36 | Crofton|work | | In file included from /usr/include/features.h:376:0, |
| 14:46.36 | Crofton|work | | from /usr/include/limits.h:27, |
| 14:46.36 | Crofton|work | | from /workspace/usrp1-e-dev/oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/python2.6/Python.h:19, |
| 14:46.39 | Crofton|work | | from numpy/core/blasdot/_dotblas.c:4: |
| 14:46.41 | Crofton|work | | /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory |
| 14:46.43 | Crofton|work | | compilation terminated. |
| 14:46.45 | Crofton|work | | In file included from /usr/include/features.h:376:0, |
| 14:46.47 | Crofton|work | | from /usr/include/limits.h:27, |
| 14:46.49 | Crofton|work | | from /workspace/usrp1-e-dev/oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/python2.6/Python.h:19, |
| 14:46.52 | Crofton|work | | from numpy/core/blasdot/_dotblas.c:4: |
| 14:46.54 | Crofton|work | | /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory |
| 14:46.56 | Crofton|work | | compilation terminated. |
| 14:46.58 | Crofton|work | | error: Command "arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -isystem/workspace/usrp1-e-dev/oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb2 -isystem/workspace/usrp1-e-dev/oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/us |
| 14:47.05 | Crofton|work | r/include -fPIC -DNO_ATLAS_INFO=2 -Inumpy/core/blasdot -I/usr/include -Inumpy/core/include -Ibuild/src.linux-x86_64-2.6/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/workspace/usrp1-e-dev/oe/tmp/sysroots/arm-angstrom-linux-gnueabi/usr/include/python2.6 -I/workspace/usrp1-e-dev/oe/tmp/sysroots |
| 14:47.10 | Crofton|work | /armv7a-angstrom-linux-gnueabi/usr/include/python2.6 -Ibuild/src.linux-x86_64-2.6/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.6/numpy/core/src/umath -c numpy/core/blasdot/_dotblas.c -o build/temp.linux-x86_64-2.6/numpy/core/blasdot/_dotblas.o" failed with exit status 1 |
| 14:47.14 | Crofton|work | | FATAL: python setup.py build_ext execution |
| 14:47.16 | Crofton|work | crap |
| 14:47.18 | Crofton|work | http://pastebin.com/Epii2yuR |
| 14:47.20 | Crofton|work | is what I meant to say |
| 14:47.21 | kergoth_ | I've seen that with natives before, usually when you don't have the 32 bit headers installed on a 64 bit box... seems odd with arm |
| 14:54.53 | *** join/#oe sgh_ (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
| 14:56.10 | hrw | /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory |
| 14:56.15 | hrw | sounds familiar |
| 14:56.52 | hrw | Crofton|work: your cross compiler was informed to look in /usr/include? |
| 14:58.05 | Crofton|work | I do not think so |
| 14:58.15 | Crofton|work | this is the python-numpy recipe |
| 14:58.20 | hrw | 16:45 < Crofton|work> r/include -fPIC -DNO_ATLAS_INFO=2 -Inumpy/core/blasdot -I/usr/include -Inumpy/core/include |
| 14:58.33 | hrw | -I/usr/include is visible |
| 14:58.58 | hrw | but OE uses sysrooted gcc... |
| 14:59.48 | Crofton|work | yeah, confusing |
| 14:59.57 | Crofton|work | I fear I need to read the recipe |
| 15:00.08 | woglinde | he crofton |
| 15:00.17 | woglinde | fighting with numpy again |
| 15:00.42 | woglinde | ieehks -i/usr/include |
| 15:02.34 | Tartarus | So, iirc |
| 15:02.43 | Tartarus | sysroot doesn't mangle -I stuff |
| 15:04.14 | Crofton | only does it on one of two machines also |
| 15:06.23 | woglinde | fishy |
| 15:07.44 | Crofton|work | yeah |
| 15:07.46 | Crofton|work | bbiab |
| 15:08.27 | *** join/#oe svolpe (~Gerrath@unaffiliated/gerrath) |
| 15:10.08 | *** join/#oe ZeeD (~ZeeD@190.187.241.83.in-addr.dgcsystems.net) |
| 15:11.29 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
| 15:28.27 | *** join/#oe grund (~grund@firebug.buglabs.net) |
| 15:39.48 | *** join/#oe janinge (j@ninge.net) |
| 15:42.34 | Unhelpful | Tartarus: i believe include paths starting w/ '=' will have that replaced w/ sysroot. |
| 15:48.25 | *** join/#oe yann (~dwitch@nan92-1-81-57-214-146.fbx.proxad.net) |
| 15:49.53 | *** join/#oe kergoth__ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 16:01.21 | *** join/#oe sgh_ (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
| 16:01.58 | Tartarus | Unhelpful, interesting.. |
| 16:08.39 | *** join/#oe dth_ntb (~dth@a89-182-92-45.net-htp.de) |
| 16:09.11 | *** join/#oe Marex (vasum7am@u-pl1.ms.mff.cuni.cz) |
| 16:09.35 | *** join/#oe Marex (vasum7am@u-pl1.ms.mff.cuni.cz) |
| 16:13.44 | *** join/#oe kgilmer (~kgilmer@ow-003-g3-1-4.oracleworld.com) |
| 16:14.57 | *** join/#oe gchiii (~gchiii@adsl-76-255-12-150.dsl.mrdnct.sbcglobal.net) |
| 16:23.42 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 16:28.18 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 16:32.05 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
| 16:32.34 | ericben | is there an easy way to overwrite a configuration file from package A by the udpated configuration file from package B ? |
| 16:32.52 | woglinde | hm |
| 16:33.03 | woglinde | normaly you shouldnt do something like that |
| 16:33.32 | ericben | example : ppp installs /etc/ppp/chap-secrets, but I want to have a myrtc-fai-pppconf, mygprs-fai-pppconf which will provide /etc/ppp/chap-secrets |
| 16:33.55 | ericben | maybe we should always split conf files from packages, so that conf files get easy to override |
| 16:34.49 | kergoth_ | why would you do that, when the package manager already understands that conffiles are special? |
| 16:35.10 | ericben | kergoth_: ok so I missed something |
| 16:35.50 | kergoth_ | CONFFILES_<pkg> informs the package manager of configuration files, so it knows not to overwrite the user's changes to them, they're not treated like other files owned by the package |
| 16:36.01 | kergoth_ | not sure how that would affect the behavior of a cross package overwrite, but keep tha tin mind |
| 16:36.10 | ericben | interesting thanks |
| 16:37.00 | ericben | other question : when using amend.inc, should'nt the package arch be MACHINE instead of the CPU arch ? |
| 16:37.11 | kergoth_ | why? |
| 16:37.18 | kergoth_ | using amend.inc doesn't mean its machine specific |
| 16:37.18 | *** join/#oe kevinsc (~a0214685@nat/ti/x-zelutlpcthmhddnq) |
| 16:37.22 | kergoth_ | you can do anything in an amend.inc |
| 16:37.37 | kergoth_ | do you mean an amend.inc that resides inside a machine specific filespath? |
| 16:37.43 | kergoth_ | thats just one of many places you can put it |
| 16:37.45 | ericben | if I have 3 overlay for 3 machines , each having a SRC_URI_append_machine |
| 16:37.46 | kergoth_ | but yes, that would be nice |
| 16:38.10 | ericben | which provides a config file for example. Actually, each time I build, the armv5 package is overwrittent |
| 16:38.25 | ericben | so I put PACKAGE_ARCH = "${MACHINE}" in amend.inc to prevent this |
| 16:38.35 | kergoth_ | yes, as expected |
| 16:38.53 | kergoth_ | the logic in base.bbclass which sets PACKAGE_ARCH automagically doesn't account for overrides, it *only* does it for you in the case wehre you use a file:// file that resides ina machine specific area of filespath |
| 16:38.57 | kergoth_ | everything else is always manual |
| 16:39.08 | ericben | ok |
| 16:39.09 | kergoth_ | amend.inc isn't special, its just another way of setting variables, it doesn't imply machine specific |
| 16:39.23 | ericben | what do you mean by "a machine specific area of filespath" ? |
| 16:39.28 | ericben | FILEPATH_machine_name ? |
| 16:39.30 | kergoth_ | no |
| 16:39.37 | kergoth_ | recipes/foo/foo-1.0/<some machine>/ |
| 16:39.41 | kergoth_ | intead of recipes/foo/foo-1.0/ |
| 16:39.43 | ericben | ok thanks |
| 16:40.01 | ericben | here is the trick I missed |
| 16:40.09 | kergoth_ | any override can be used there, filespath is assembled from 1) FILESPATHBASE, 2) FILESPATHPKG, 3) OVERRIDES, in that order |
| 16:41.05 | *** join/#oe SAn (~san@201.255.25.184) |
| 16:41.47 | ericben | ok, last thing : for amend.inc, can I have recipe/package/files/machinename/conffile and nothing in amend.inc if the recipe in OE's tree also have conffile ? |
| 16:42.53 | ericben | in fact I added to my local.conf : INHERIT += "amend" and FILEPATHBASE =. "${BBFILE_PATTERN_mycollection}/:" |
| 16:42.59 | ericben | maybe this is wrong |
| 16:45.40 | kergoth_ | that won't work |
| 16:45.48 | kergoth_ | that'll put the root of your collection into the filespath |
| 16:45.54 | pb_ | g'day kergoth |
| 16:45.57 | kergoth_ | not the recipe/<whatever>/ dir relative to your collection |
| 16:46.43 | kergoth_ | you'll need a python snippet in filespathbase to add <collection>/recipes/<basename of FILE_DIRNAME>/ for each collection |
| 16:46.47 | ericben | kergoth_: ok so in fact for amend, it's better to create on directory which will contains all the amends ? |
| 16:46.52 | kergoth_ | see the mailing list archives, someone has done it on multiple occasions |
| 16:46.57 | kergoth_ | not sure what you mean |
| 16:47.09 | kergoth_ | supplying different config files using FILESPATH doesn't require amend.inc at all |
| 16:47.12 | kergoth_ | they're two independent things |
| 16:48.21 | ericben | ok thanks for these informations, I better understand and will search again the lists archive for more details. |
| 16:48.37 | kergoth_ | np |
| 16:48.40 | kergoth_ | hey pb_ |
| 17:12.07 | *** join/#oe pH5 (~ph5@e178206207.adsl.alicedsl.de) |
| 17:17.39 | *** join/#oe CMoH (~cipi@95.76.71.81) |
| 17:19.47 | *** join/#oe kgilmer (~kgilmer@adsl-76-231-184-89.dsl.pltn13.sbcglobal.net) |
| 17:20.49 | *** join/#oe pcacjr (~pcacjr@187.59.240.56) |
| 17:20.49 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 17:22.37 | *** join/#oe janinge (j@ninge.net) |
| 17:26.53 | *** join/#oe robtow (~rob@64.62.142.114) |
| 17:27.54 | *** join/#oe JDuke128 (~kadir@81.214.22.138) |
| 17:28.58 | JDuke128 | hi , i tried lsusb to find my huwaei e620 modem path but its just giving ID , no path like : "/dev/ttyUSB2" , how can i get full path of device ? or i need to mount it ? |
| 17:30.47 | ericben | ok kergoth_ : FILESPATHBASE =. "${@ ':'.join([os.path.join(recipedir, os.path.basename(os.path.dirname( d.getVar('FILE', 1)))) for recipedir in d.getVar('COLLECTIONS', 1).split()])}:" seems to be the magic line |
| 17:31.50 | ericben | now if I put initscripts/files/mymachine/alignement.sh I see bitbake initscript uses this file |
| 17:33.07 | ericben | but it still builds a armv5 package, not a mymachine package : isn't files/mymachine the correct place to put the file ? or is it because initscripts is using an overide (_arm) to add this file to the package ? |
| 17:33.17 | *** join/#oe dromede (~quassel@78-0-199-65.adsl.net.t-com.hr) |
| 17:33.37 | *** join/#oe janinge (j@ninge.net) |
| 17:39.53 | *** join/#oe tasslehoff (~anders@145.79-161-31.customer.lyse.net) |
| 17:46.19 | *** join/#oe arun_ (~arun@unaffiliated/sindian) |
| 17:49.14 | khem | ericben: why dont you use BBLAYERS |
| 17:49.21 | khem | and BBAPPEND |
| 17:49.49 | khem | http://sakrah.dontexist.org/node/2 |
| 17:59.11 | *** part/#oe grund (~grund@firebug.buglabs.net) |
| 18:01.36 | khem | 8 |
| 18:08.21 | *** join/#oe loadammo (~root@38.104.194.118) |
| 18:09.01 | *** join/#oe Jay7 (jay@93-81-3-20.broadband.corbina.ru) |
| 18:09.43 | loadammo | I'm trying to figure out the preferred version for a package included in my image, inside the image's recipe -- tried getEnv and that didn't work.. Anyone run into this? Reasoning is I want to tag the OS image not only with the svn of the OS build, but also tag it with the SVN rev of the 'most important package' I'm installing |
| 18:09.53 | loadammo | any help would be greatly appreciated |
| 18:12.30 | *** join/#oe anarsoul (~anarsoul@80.249.94.19) |
| 18:13.00 | khem | loadammo: recipe specific metadata may not be available globally |
| 18:13.29 | loadammo | Hmm, noted. |
| 18:14.17 | khem | loadammo: although you could enquire metadata for the version |
| 18:14.33 | khem | in a python snippet and see if bitbake allows that |
| 18:14.41 | loadammo | ahh, good idea |
| 18:14.56 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 18:17.03 | khem | loadammo: PV/PR would have given you this info |
| 18:17.08 | khem | and they are recipe specific |
| 18:17.15 | *** join/#oe vanous (~vanous@194.228.223.3) |
| 18:18.11 | loadammo | Yeah, I got that part sorted no problem.. I just want to make it part of the image recipe without using an intermediary temp file somewhere.. The image has to know what the preferred version is for do_rootfs, I imagine.. so I think it's 'in there'.. Just gotta find it. |
| 18:18.34 | *** join/#oe Martin-B (~martin@pool-73-65-198-89.dbd-ipconnect.net) |
| 18:19.08 | khem | loadammo: no image knows there is only 1 version built |
| 18:19.20 | khem | parsing phase decides the preferred version |
| 18:19.22 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 18:19.28 | khem | I dont know if this info is available globally |
| 18:19.36 | loadammo | ok |
| 18:20.23 | khem | may be you can define a new global var |
| 18:20.29 | khem | for your purpose |
| 18:20.36 | khem | as the package is important to you |
| 18:20.50 | *** join/#oe kgilmer (~kgilmer@216.131.196.2) |
| 18:20.52 | khem | then use metadata_scm.bbclass to extract the info |
| 18:21.09 | khem | and populate this var when this recipe is built |
| 18:21.35 | loadammo | Hmm.. |
| 18:26.15 | *** join/#oe dth_ntb (~dth@a89-182-92-45.net-htp.de) |
| 18:27.05 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 18:27.52 | *** join/#oe stefan_schmidt (~stefan@p5B036F21.dip.t-dialin.net) |
| 18:32.01 | *** join/#oe sgh (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
| 18:38.10 | *** join/#oe svolpe (~Gerrath@unaffiliated/gerrath) |
| 18:47.05 | *** join/#oe svolpe (~Gerrath@unaffiliated/gerrath) |
| 18:59.59 | tasslehoff | khem: I've had some issues with the sdk's I compile. I talked to zecke about it, and I seem to recall him saying you were one of the guys he was going to seek advice with. Does that seem right? Warning: If so, I have a couple of questions :) |
| 19:00.24 | khem | tasslehoff: sure toss the questions |
| 19:02.51 | tasslehoff | khem: my sdk's have worked well in the past but after a fetch of upstream a month (or two) ago gcc won't launch. it complains about missing libmpfr.so.4, which is a library neither on my Ubuntu 10.04 host, nor in the SDK. It can only be found in my TMPDIR. |
| 19:03.09 | khem | tasslehoff: yes |
| 19:03.23 | khem | thats because we use latest version |
| 19:03.29 | khem | and most distros dont have it yet |
| 19:03.44 | khem | this so is expected to be on the host |
| 19:04.00 | tasslehoff | khem: does that mean that a compiled sdk cannot be used on most distros? or is there a way around it? |
| 19:04.05 | khem | tasslehoff: there arw two ways to solve it |
| 19:04.23 | khem | 1. package the required .so with the SDK |
| 19:04.35 | khem | i.e. your host systroot |
| 19:04.54 | khem | 2. link these into gcc statically |
| 19:04.59 | khem | 3. downgrade |
| 19:05.11 | khem | I am in favor or 2 |
| 19:05.17 | khem | s/or/of |
| 19:05.28 | khem | but that needs some work in gcc |
| 19:05.41 | khem | easiest would be to downgrade |
| 19:05.54 | khem | modular would be to package them with SDK |
| 19:06.22 | tasslehoff | khem: hm. downgrade my entire OE you mean? |
| 19:06.27 | khem | no |
| 19:06.30 | khem | just mpfr |
| 19:06.39 | khem | see currently what happens |
| 19:06.59 | khem | you build the toolchain SDK on a given host and it builds against the libraries that are built by OE |
| 19:07.24 | khem | then you move the SDK to a different host and it starts to use the libraries provided by host |
| 19:07.28 | khem | thats wrong IMP |
| 19:07.30 | khem | IMO |
| 19:07.42 | khem | because you did not target the SDK for that given host |
| 19:08.08 | khem | if possible I would suggest that you package these libraries along with SDK |
| 19:08.31 | tasslehoff | khem: yeah. it was a mystery to me for a white that the sdk worked only on my computer. until I found out that the gcc had an rpath into the sysroot-directory of the tree where I built it. |
| 19:08.44 | khem | yes |
| 19:09.03 | tasslehoff | s/white/while :) |
| 19:09.31 | khem | we could link these libraries statically into gcc |
| 19:09.36 | khem | that will make it more portable |
| 19:09.41 | khem | but beef up gcc |
| 19:10.11 | khem | and packing them along with SDK is not a bad idea either |
| 19:10.12 | tasslehoff | khem: maybe a stupid Q, but why would it not be possible to package those libraries along with the SDK? do you mean a manual packing, or modifying the sdk-recipes to fix it? |
| 19:11.27 | tasslehoff | khem: I thought about just picking up one compile error at a time, and copy the needed library from sysroot into the lib-folder of my unpacked toolchain. |
| 19:11.57 | khem | yes that could be a way to find |
| 19:12.14 | tasslehoff | I think it was just 2 or 3 the last time I checked. |
| 19:12.38 | khem | tasslehoff: yes libelf, libmpfr libmpc libgmp |
| 19:12.43 | *** join/#oe JaMa (~martin@161-24.13.24.78.awnet.cz) |
| 19:12.45 | khem | these are 4 thats needed |
| 19:12.48 | khem | by gcc |
| 19:12.51 | khem | as of now |
| 19:12.59 | khem | there may be more that come in future who known |
| 19:13.41 | *** join/#oe pb__ (~pb@blundell.swaffham-prior.co.uk) |
| 19:14.26 | Tartarus | The best answer is to make gcc link vs them statically |
| 19:14.46 | Tartarus | Since shipping them means relocation gets much harder and you have to use chrpath and mangle them |
| 19:14.53 | Tartarus | which isn't overly hard |
| 19:14.57 | Tartarus | But is more work |
| 19:15.02 | khem | Tartarus: right |
| 19:15.06 | khem | I am all for it |
| 19:15.12 | Tartarus | and statically linking them is easy |
| 19:15.15 | khem | I could propose a patch |
| 19:15.37 | khem | yes and it will speed up compilation a bit |
| 19:15.49 | Tartarus | Er? |
| 19:15.54 | Tartarus | Building and using our own static libs? |
| 19:16.06 | khem | yes if gcc links them statically |
| 19:16.08 | *** join/#oe kergoth__ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 19:16.19 | khem | the resulting gcc will compile stuff faster I meant |
| 19:16.38 | Tartarus | that almost sounds like noise, heh |
| 19:17.55 | tasslehoff | khem: thanks for the answers. I'll do the ship-libs-with-sdk to begin with |
| 19:17.57 | pb__ | I doubt you could measure any performance boost from a static linked gcc versus a regular dynamic one. |
| 19:18.22 | pb__ | Static linking would be a win in some ways, a loss in others, but all the effects are going to be miniscule on a program like gcc. |
| 19:18.23 | khem | pb__: sure |
| 19:18.39 | khem | thats why I said a bit |
| 19:19.03 | pb__ | heh. well, you could equally well argue that it would make it "a bit" slower. :-} |
| 19:19.15 | khem | haha true |
| 19:19.32 | Tartarus | It's also really easy to do, more importantly |
| 19:19.33 | Tartarus | sec |
| 19:19.50 | Tartarus | http://pastebin.com/PZjdk0Mw |
| 19:19.52 | pb__ | yeah, I certainly don't think it's a bad idea |
| 19:19.57 | *** join/#oe timtimred (~meh@79-69-168-194.dynamic.dsl.as9105.com) |
| 19:19.59 | Tartarus | + having --enable-static in mpfr-native |
| 19:20.03 | Tartarus | (and gmp-native) |
| 19:20.07 | pb__ | yeah |
| 19:20.11 | khem | so if we have agreement then we could work on linking gcc with mpfr and friends statically |
| 19:20.33 | pb__ | khem: sounds like you are too slow :-) |
| 19:20.59 | pb__ | Tartarus: looks like a decent plan. I can't think of any downside to doing that. |
| 19:21.07 | khem | Tartarus: do you need that Makefile hackery at all |
| 19:21.16 | khem | pb__: indeed |
| 19:21.20 | Tartarus | khem, uyes |
| 19:21.21 | Tartarus | yes |
| 19:21.22 | Tartarus | iirc |
| 19:21.45 | khem | Tartarus: --with-mpfr-lib option and friends |
| 19:21.50 | khem | will be better IMP |
| 19:21.52 | khem | IMO |
| 19:21.59 | Tartarus | Don't think it worked |
| 19:22.02 | Tartarus | kergoth, recall? |
| 19:22.16 | khem | even when you gave it a/b/c/libmpfr.a ? |
| 19:22.34 | Tartarus | checks |
| 19:23.53 | Tartarus | khem, give that a whirl I guess :) |
| 19:24.09 | Tartarus | I know the above works, but yes, it could be cleaner if --with-mpfr-lib works w/ a full path |
| 19:24.36 | khem | <PROTECTED> |
| 19:24.45 | khem | to these libs will also do it |
| 19:25.18 | Tartarus | That didn't |
| 19:25.31 | Tartarus | That'd pick up shared from the host |
| 19:25.32 | khem | hmmm strange so it defaulted to one on the build box ? |
| 19:25.36 | khem | ok |
| 19:25.45 | khem | so its hell bent on getting shared |
| 19:25.49 | Tartarus | yes |
| 19:26.05 | Tartarus | Don't recall for certain if we tried --with-mpfr-lib=a/b/c/libmpfr.a |
| 19:26.14 | Tartarus | But I know we tried just doing static only of our libs |
| 19:26.16 | Tartarus | and it went host |
| 19:26.20 | khem | Tartarus: but if I put these libraries in gcc src dir then it links them in statically |
| 19:26.33 | Tartarus | Yes, we also tried that pat |
| 19:26.33 | Tartarus | hh |
| 19:26.38 | Tartarus | But it wasn't as clean to implement |
| 19:27.03 | Tartarus | ends up being a pain to patch the gmp/mpfr/etc sources like we do for -native |
| 19:27.55 | khem | I kind of see why dynamic is default |
| 19:28.09 | Tartarus | it's not 1996 anymore, yes ;) |
| 19:28.10 | khem | a bug fix in mpfr would otherwise trigger gcc update too |
| 19:29.39 | khem | Tartarus: build/install gmp/mpfr yourself and specify --disable-shared to |
| 19:29.40 | khem | both. Then use --with-mpfr= to specify using them instead of the system's |
| 19:29.40 | khem | shared versions. |
| 19:29.44 | khem | should work |
| 19:30.01 | *** join/#oe anarsoul_ (~anarsoul@80.249.83.140) |
| 19:30.05 | khem | lemme try that out |
| 19:30.48 | Tartarus | I think we just added static libs to mpfr/etc just ot be safe in case of other users |
| 19:31.02 | *** join/#oe anarsoul_ (~anarsoul@80.249.83.140) |
| 19:31.32 | khem | Tartarus: other host packages you mean ? |
| 19:31.53 | khem | we dont loose much if they link with static versions do we ? |
| 19:32.37 | Tartarus | They'd be in the picking up host shared lib |
| 19:32.40 | Tartarus | WHich isn't desirable |
| 19:33.41 | khem | hmm |
| 19:34.15 | *** join/#oe DJWillis (~djwillis@cpc1-bath2-0-0-cust327.aztw.cable.virginmedia.com) |
| 19:35.19 | *** join/#oe anarsoul (~anarsoul@80.249.83.140) |
| 19:40.32 | khem | Tartarus: all in all that patch of yours look on |
| 19:40.36 | khem | ok |
| 19:40.58 | khem | Tartarus: you may only need to patch Makefile.tpl |
| 19:41.05 | khem | as Makefile.in is generated from that |
| 19:45.09 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 19:50.52 | *** join/#oe awozniak (~awozniak@adsl-76-205-222-173.dsl.snlo01.sbcglobal.net) |
| 19:56.04 | ericben | hi khem, yes I found this blog page about bblayes & bbappend through google this afternoon, are you the author ? |
| 19:56.12 | Tartarus | khem: Yeah |
| 19:56.20 | Tartarus | We hit 'em both since other Makefile mangling hit them both |
| 19:56.57 | khem | ericben: yes |
| 19:57.14 | khem | Tartarus: I am testing your patch with other bits around it |
| 19:57.49 | ericben | khem: is the bblayer concept applicable to overlay I already have ? |
| 19:58.05 | khem | ericben: should be |
| 19:58.13 | khem | ericben: use bitbake master though |
| 19:58.14 | ericben | seems the answer is yes from what I understand on your page |
| 19:58.19 | khem | I am not sure older bitbake will work |
| 19:58.21 | ericben | ok, I'll try |
| 19:59.45 | ericben | I still don''t understand everything on how the packages get built for PACKAGE_ARCH=MACHINE or for generic arch |
| 20:07.20 | fraxinath | guys, i've stumbled upon something weird |
| 20:08.03 | fraxinath | gcc-cross-4.4.3-r0.1/gcc-4.4.3/libjava/classpath/configure always sets a GMP_CFLAGS=-I/usr/include after configure task |
| 20:08.10 | fraxinath | even though i've fixed it in the configure.ac |
| 20:08.35 | fraxinath | i have no idea where it takes that from and of course it leads to a "cross compile badness" error in compile task |
| 20:08.58 | fraxinath | has anybody noticed that already? |
| 20:09.10 | khem | fraxinath: hmmm are you on latest master |
| 20:09.31 | fraxinath | no using dreambox-1.6 fork |
| 20:09.36 | fraxinath | opendreambox |
| 20:09.51 | khem | there are fixes in upstream OE |
| 20:10.00 | fraxinath | for that very issue? |
| 20:11.12 | fraxinath | uhm... master doesn't have 4.4.3 anymore at all ?? |
| 20:12.10 | *** join/#oe mrc3 (~mrc3@nat/ti/x-gdxdvpfxvhrufhyt) |
| 20:12.17 | khem | fraxinath: its 4.4.4 |
| 20:12.23 | khem | you could use it |
| 20:13.25 | fraxinath | ooooh not sure what all that would break though |
| 20:13.48 | fraxinath | is there a particular reason why the 4.4.3 recipe was taken out of the repo all the way |
| 20:13.50 | fraxinath | ? |
| 20:14.07 | khem | it was moved to 4.4.4 |
| 20:14.30 | khem | 4.4.4 is bugfix release which will have all 4.4.3+new bug fixes |
| 20:14.48 | fraxinath | ah okay only bugfixes, that sounds good |
| 20:19.41 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 20:22.07 | *** join/#oe GNUtoo|laptop (~gnutoo@host55-144-dynamic.54-79-r.retail.telecomitalia.it) |
| 20:31.29 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 20:32.04 | ericben | kergoth_: earlier, you explained me the logic of PACKAGe_ARCH which is automagically set to MACHINE in case we use a file:// which is in a machine specific are of filespath. I'm trying this with initscripts-1.0/mymachine and I always get a armv5te package for initscripts. I've tested to add the filees to the overlay (with correct FILESPATH) or directly in OE's tree and I always get the same result : the file is included in the package, but |
| 20:37.47 | khem | ericben: is this recipe machine speicific |
| 20:39.02 | ericben | khem: from what I understood, as soon as it gets a file:// in initscripts-1.0/machine/ directory the package becomes machine specific |
| 20:39.11 | khem | hmmm |
| 20:39.38 | Jay7 | seems Cisco is hiring embedded developers.. |
| 20:39.52 | khem | PACKAGE_ARCH=${MACHINE_ARCH} |
| 20:39.54 | khem | you need that |
| 20:40.00 | khem | Jay7: yes indeed they are |
| 20:40.12 | khem | Jay7: and Cisco uses OE too |
| 20:40.56 | khem | ericben: I dont think that it will turn the recipe into machine specific recipe automatically |
| 20:40.58 | Jay7 | I've received proposal.. |
| 20:41.21 | khem | Jay7: r u interested ? |
| 20:41.24 | Jay7 | Sr.Software Engineer |
| 20:41.45 | Jay7 | I don't like idea of relocation into USA.. |
| 20:41.55 | khem | I dont think they care |
| 20:42.01 | Jay7 | I like Europe :) |
| 20:42.02 | khem | you can work whereever you are |
| 20:42.33 | Jay7 | I'll ask about this |
| 20:42.55 | ericben | khem: in base.bbclass, it tests for is_machine_specific, which is in utils.bbclass and tests if SRC_URI contains machinepath |
| 20:43.35 | khem | hmm |
| 20:43.40 | khem | ericben: ok I see |
| 20:48.19 | CIA-68 | 03Eric Bénard <eric@eukrea.com> 07org.openembedded.dev * r907d0ce00d 10openembedded.git/recipes/python/python.inc: |
| 20:48.19 | CIA-68 | python: increase PR |
| 20:48.19 | CIA-68 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
| 20:48.19 | CIA-68 | 03Eric Bénard <eric@eukrea.com> 07org.openembedded.dev * rbe576ab8af 10openembedded.git/recipes/python/python-2.6-manifest.inc: |
| 20:48.19 | CIA-68 | python-2.6-manifest.inc: regenerate the file |
| 20:48.19 | CIA-68 | the patch is quite large because packages seems to have been reordered |
| 20:48.20 | CIA-68 | in the generator but excepting python-dev everything is still present. |
| 20:48.20 | CIA-68 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
| 20:48.21 | CIA-68 | Acked-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 20:48.21 | CIA-68 | 03Eric Bénard <eric@eukrea.com> 07org.openembedded.dev * r22c71d47e4 10openembedded.git/recipes/python/python_2.6.5.bb: |
| 20:48.22 | CIA-68 | python_2.6.5: tune python-distutils |
| 20:48.22 | CIA-68 | removing config/libpython2.6.a and distutils/command/win* |
| 20:48.23 | CIA-68 | as suggested by cdricjulien. |
| 20:48.24 | CIA-68 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
| 20:48.24 | CIA-68 | Acked-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 20:48.25 | CIA-68 | 03Eric Bénard <eric@eukrea.com> 07org.openembedded.dev * re239d07dfc 10openembedded.git/contrib/python/generate-manifest-2.6.py: |
| 20:54.24 | khem | ericben: hmmm so you are having trouble when using bblayer or in general |
| 20:55.48 | ericben | actually I'm not using bblayer (not yet). I have a machine overly and used FILESPATHBASE to add files into it (after reading explanations from kergoth_ ) |
| 20:56.01 | ericben | this seems to work as my file is used to build initscripts |
| 20:56.47 | ericben | but initscripts's ipk is always armv5te and not machine specific (which is what seems to be the case on angstrom : http://www.angstrom-distribution.org/repo/?pkgname=initscripts |
| 20:57.33 | ericben | so as I was not sure of FILESPATHBASE change, I removed it and put my file in oe's tree in recipes/initscripts/initscripts-1.0/mymachine/ |
| 20:57.38 | ericben | and the package is still armv5 |
| 20:58.22 | *** join/#oe pb__ (~pb@blundell.swaffham-prior.co.uk) |
| 20:58.58 | ericben | which means if I build 3 different armv5 machines in the same tree, the initscript package will always be the one of the last machine (and be in deploy/glibc/ipk/armv5te instead of deploy/glibc/ipk/mymachine) |
| 20:59.46 | ericben | I'm trying a fresh build to see if that works or if this is because on my overlay or my machine orr something else in my current working tree |
| 21:00.33 | khem | ericben: it works ok for me to have machine specific recipes e.g. uclibc |
| 21:00.38 | khem | or sysvinit |
| 21:00.40 | khem | works ok here |
| 21:01.34 | ericben | here also ok for sysvinit-inittab, but not for initscripts ! |
| 21:02.17 | ericben | well sysvinit-inittab is set as MACHINE_ARCH in the recipe so this is expected |
| 21:02.49 | *** join/#oe jamuraa_ (~jamuraa@c-75-72-149-7.hsd1.mn.comcast.net) |
| 21:16.27 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 21:30.10 | yann | hi there - anyone to review patches http://patchwork.openembedded.org/patch/2959/ to 2961 ? |
| 21:32.05 | *** join/#oe kgilmer (~kgilmer@216.131.196.2) |
| 21:32.07 | yann | I have listed my gnugo patch as defered, there is an issue when cross-compiling from 64bit to 32 and vice versa |
| 21:32.19 | yann | (discussing a fix with upstream) |
| 21:32.32 | khem | yann: yes I have |
| 21:38.42 | *** join/#oe meindian523 (~easwar@unaffiliated/easwar) |
| 21:42.46 | yann | khem: any comment ? |
| 21:43.19 | khem | yann: looks ok to me thougj |
| 21:43.30 | khem | yann: what DISTRO did you try it on |
| 21:47.32 | yann | shr-testing |
| 21:59.54 | khem | yann: could you try it with angstrom |
| 22:00.02 | khem | and see if the sizes are fixed |
| 22:00.05 | khem | for git-native |
| 22:02.34 | *** join/#oe kgilmer (~kgilmer@216.131.196.2) |
| 22:11.11 | fraxinath | khem: gcc-cross_4.4.4 doesn't configure |
| 22:11.39 | fraxinath | aclocal: /dream/oe1.6/dm8000/build/tmp/work/mipsel-oe-linux/gcc-cross-4.4.4-r6.0/gcc-4.4.4/libstdc++-v3/acinclude.m4:2989: file `../config/tls.m4' does not exist |
| 22:12.48 | khem | fraxinath: did u build from scratch |
| 22:13.09 | fraxinath | i built that package |
| 22:13.14 | *** join/#oe ant_ (~andrea@host196-249-dynamic.4-87-r.retail.telecomitalia.it) |
| 22:14.13 | fraxinath | do i first need gcc-cross-initial and intermediate? |
| 22:14.21 | khem | yes |
| 22:14.24 | fraxinath | aye |
| 22:14.25 | khem | you need to do it |
| 22:14.26 | fraxinath | i'll try |
| 22:14.53 | khem | bitbake -c clean gcc-cross gcc-cross-intermediate gcc-cross-initial glibc glibc-initial |
| 22:15.02 | khem | then bitbake gcc-cross |
| 22:15.21 | khem | assuming you have gcc-4.4.4 as your default gcc-cross provider |
| 22:15.44 | fraxinath | i think 4.4.3 is preferred by something else right now |
| 22:16.22 | fraxinath | if i just do bitbake gcc-cross-initial then it will try building 4.4.3 again |
| 22:16.56 | fraxinath | oh i almost forgot that glibc also depends on it |
| 22:17.02 | fraxinath | that'll take all night :) |
| 22:17.57 | khem | depending upong your machine |
| 22:18.14 | khem | some folks build whole OE distro under 2 hrs here |
| 22:18.46 | fraxinath | conf/distro/opendreambox.conf:PREFERRED_GCC_VERSION ?= "4.4.3" |
| 22:19.06 | khem | add PREFERRED_GCC_VERSION_local = "4.4.4" in your local.conf |
| 22:19.34 | fraxinath | i'll try changing it in there for right now |
| 22:19.37 | fraxinath | AMD Phenom(tm) 9550 Quad-Core Processor |
| 22:19.43 | fraxinath | with 8 gb ram |
| 22:19.51 | fraxinath | but it's slow as all hell when it comes to bitbake |
| 22:20.09 | khem | fraxinath: your machine is decent |
| 22:21.54 | ant_ | we had improvements after the cleaning storm... |
| 22:22.07 | ant_ | shame tinderbox is broken |
| 22:22.31 | ant_ | iirc console-image in 50 mins from scratch (xeon quad + 8GB) |
| 22:22.53 | ant_ | old hw nowaday |
| 22:23.21 | loadammo | Hmm |
| 22:23.24 | ant_ | ImportError: Could not import settings 'tinderbox.settings' (Is it on sys.path? Does it have syntax errors?): No module named oestats.settings |
| 22:23.35 | loadammo | I do console-image in about 20 mins here, 16 cores, 16gb ram |
| 22:23.46 | fraxinath | poser :) |
| 22:23.49 | loadammo | shared with a bunch of folks tho |
| 22:24.04 | fraxinath | okay building 4.4.4 now khem! thanks for the clues |
| 22:24.20 | loadammo | <3 OE |
| 22:25.04 | khem | loadammo: cool |
| 22:25.04 | fraxinath | lol same configure error |
| 22:25.56 | loadammo | Heh, OE is actually the only thing that puts 'real' load on this build machine. Everyone else barely even bothers to use -j |
| 22:26.01 | ericben | khem: found the bug which prevent initscript to automagicaly be in machine_arch instead of generic arch |
| 22:26.14 | khem | ericben: cool what is it |
| 22:26.18 | ericben | I'll send a patch to the ml for review |
| 22:26.52 | ericben | urldata.path is used instead of urldata.localpath in is_machine_specific |
| 22:27.44 | khem | ugh thats obvious problem |
| 22:27.45 | khem | :) |
| 22:27.47 | ericben | and urldata.path does'nt contains the full path, so when compared to the expected path to machine filepathpkg it fails |
| 22:28.00 | khem | yes this is due to recent fix in bb |
| 22:28.07 | ericben | 4 hours to understand this proble :) |
| 22:28.08 | khem | btw what version of bb are u using |
| 22:28.13 | ericben | bb : head |
| 22:28.16 | khem | ok |
| 22:28.25 | khem | also try this with 1.8 if you could |
| 22:28.29 | khem | I guess it will break |
| 22:28.47 | fraxinath | khem any idea about aclocal: /dream/oe1.6/dm8000/build/tmp/work/mipsel-oe-linux/gcc-cross-4.4.4-r6.0/gcc-4.4.4/libstdc++-v3/acinclude.m4:2989: file `../config/tls.m4' does not exist ? |
| 22:29.06 | ericben | in fact, the problem seem to be introduced by commit : 2b7ea6f52dfa7c6cdbbb426e13efba1b4914e7b9 (I'm not 100% sure but this is where this function was introduced) |
| 22:29.28 | ericben | trying 1.8.18 |
| 22:29.28 | ant_ | khem: about this arches, no way to unbind klibc from machine? |
| 22:29.58 | khem | ericben: it was the semantic of urldata |
| 22:30.19 | khem | fraxinath: I havent seen this error before |
| 22:30.26 | *** join/#oe angelox_123 (~Angelo@201-95-91-248.dsl.telesp.net.br) |
| 22:30.37 | fraxinath | me neither |
| 22:30.59 | khem | fraxinath: are you seeing it on master |
| 22:31.07 | *** join/#oe joshc_ (~joshc@cpe-24-28-84-71.austin.res.rr.com) |
| 22:31.10 | khem | or did you do selective port into dreambox |
| 22:31.11 | khem | branch |
| 22:31.31 | khem | if you are doing selective backport |
| 22:31.36 | khem | take complete gcc dire |
| 22:31.36 | fraxinath | i checked out the whole 4.4.4 stuff into our repo |
| 22:32.01 | ericben | khem: seems to work also with 1.8.18 |
| 22:32.09 | khem | ericben: perfect |
| 22:32.19 | fraxinath | i'll try it with entire gcc dir |
| 22:32.21 | khem | ant_: which arch |
| 22:32.30 | ericben | cleaning the mess I put in class/ to understand it and preparing a patch |
| 22:32.47 | khem | I wish I had a crystal ball |
| 22:32.56 | ericben | and the hardest thing in the patch : the commit message :) |
| 22:33.49 | ynezz | ou yeah |
| 22:40.01 | khem | ericben: -m "Fix broken recipe" |
| 22:40.06 | khem | and I will reject it |
| 22:40.43 | ericben | :) |
| 22:41.29 | ericben | testing with the overlay and FILEPATHBASE |
| 22:42.53 | khem | ericben: ok |
| 22:44.38 | ericben | for tindderboox, if there is interest, I can provide one on one of our servers, I've one private oestat already setup, duplicating it is a matter of minutes |
| 22:44.59 | khem | ericben: sure |
| 22:45.18 | ant_ | khem: i.e. other *libc are armv5te but klibc is c7x0 |
| 22:45.24 | khem | ericben: if you can help fixing tinderbox.openemebedded.org that will be nice too |
| 22:45.39 | khem | ant_: same issue with uclibc |
| 22:45.43 | ant_ | khem: so is klcc-cross (but the empty package is not created) |
| 22:46.15 | fraxinath | is any of you guys gonna be at CELF in cambridge next month? |
| 22:46.20 | ericben | khem: if you want, we can try to setup it from sscratch |
| 22:46.39 | khem | ericben: hmm will be loose the logs |
| 22:47.18 | ericben | no I think we can restore logs after, they are stored in a separated irectory |
| 22:47.39 | fraxinath | khem: gcc-cross-initial_4.4.4 configures successfully when i overwrite the entire gcc directory from master |
| 22:47.55 | ant_ | yes, rename tmp and reate an empty one |
| 22:48.12 | *** join/#oe Spz0 (~a@97-120-161-26.ptld.qwest.net) |
| 22:48.13 | ericben | the major diference is that oe's tinderbox is using mysql and I'm using sqlite here |
| 22:48.35 | ant_ | fwiw oe tinderbox is having hard times... |
| 22:48.45 | khem | ericben: ok |
| 22:48.58 | ant_ | MOD_PYTHON ERROR |
| 22:49.00 | ant_ | heh |
| 22:49.02 | khem | ericben: lets try it with sqlite |
| 22:49.08 | ericben | ok that works also in the overlay |
| 22:49.23 | ericben | khew, I can send you the doc I wrote for my setup |
| 22:49.55 | khem | ericben: ok |
| 22:50.07 | khem | and also how can we restore the logs |
| 22:50.11 | fraxinath | i'll let that continue baking and hope for the best for tomorrow morning :) thanks again and cu |
| 22:50.12 | khem | bugzilla is also boked |
| 22:50.22 | khem | fraxinath: bye |
| 22:50.37 | ericben | sqlite will be the 1st step |
| 22:50.55 | ericben | after you need to switch back to mysql to restore everything |
| 22:51.29 | khem | ericben: is sqlite better performant |
| 22:52.14 | ant_ | well, cgit.openembedded.org is working, tinderbox not. both on 140.211.169.165 |
| 22:52.37 | ant_ | seems just a missing config file |
| 22:52.55 | khem | ant_: what do you mean by missing file |
| 22:52.58 | ant_ | http://tinderbox.openembedded.net/ |
| 22:53.05 | ant_ | see here, last line |
| 22:53.05 | khem | its a different set of beast |
| 22:53.38 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 22:53.49 | ericben | it the server apache or lighttpd ? |
| 22:53.55 | khem | apache |
| 22:54.59 | ericben | do you have the apach conf for tinderbox.oe.org ? |
| 22:55.05 | khem | yes |
| 22:55.09 | ericben | is PythonPath properly setup insode ? |
| 22:55.21 | ericben | and DJANGO_SETTINGS_MODULE ? |
| 22:56.45 | khem | SetEnv DJANGO_SETTINGS_MODULE tinderbox.settings |
| 22:56.54 | khem | PythonPath "['/etc/django-oestats'] + sys.path" |
| 22:57.06 | ericben | ls /etc/django-oestats ? |
| 22:57.11 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 22:58.48 | *** join/#oe andyj (~andy@c-76-28-141-180.hsd1.wa.comcast.net) |
| 22:59.32 | khem | settings.py is in there |
| 22:59.36 | khem | /etc/django-oestats/tinderbox/ |
| 23:00.29 | khem | from oestats.settings import * |
| 23:00.39 | khem | thats where it chickens out |
| 23:03.22 | ericben | ok ls /usr/lib/pymodules/python2.6/oestats ? |
| 23:03.35 | khem | robots.txt |
| 23:03.47 | ericben | only that ? |
| 23:03.51 | khem | yes |
| 23:03.52 | khem | :) |
| 23:03.59 | ericben | ok python was updated no ? |
| 23:04.05 | ericben | ok ls /usr/lib/pymodules/python2.5/oestats ? |
| 23:04.06 | khem | it was |
| 23:04.12 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
| 23:04.29 | khem | no 2.5 |
| 23:04.50 | ericben | search for oestats in /usr/lib |
| 23:05.29 | khem | /usr/lib/pymodules/python2.6/oestats |
| 23:05.31 | khem | thats it |
| 23:05.49 | ericben | and it's empty ? |
| 23:05.57 | khem | yes |
| 23:06.10 | ericben | ok |
| 23:06.27 | ericben | backup /etc/django-oestats |
| 23:07.09 | ericben | then follow the instructions here to build the .deb http://opensource.bolloretelecom.eu/projects/django-oestats/ @ Running a production server |
| 23:07.12 | ericben | then install it |
| 23:07.23 | ericben | then recover backup of settings.py |
| 23:07.49 | ericben | in ls /usr/lib/pymodules/python2.6/oestats |
| 23:07.49 | ericben | admin.py __init__.py models.py settings.pyc templatetags views.pyc |
| 23:07.49 | ericben | admin.pyc __init__.pyc models.pyc shortcuts.py urls.py |
| 23:07.49 | ericben | forms.py middleware.py public shortcuts.pyc urls.pyc |
| 23:07.51 | ericben | forms.pyc middleware.pyc settings.py templates views.py |
| 23:07.57 | ericben | this is what you should have after that |
| 23:18.48 | khem | ericben: PythonHandler django.core.handlers.modpython |
| 23:18.53 | khem | is erroring out |
| 23:19.03 | khem | Invalid command 'PythonHandler', perhaps misspelled or defined by a module not included in the server configuration |
| 23:20.02 | ericben | is django installed from scratch or from debian's package ? |
| 23:21.42 | ericben | if not installed : http://docs.djangoproject.com/en/dev/topics/install/#installing-official-release |
| 23:22.39 | ericben | whaht says django-admin --version |
| 23:22.43 | khem | ericben: ok installed from .dev |
| 23:22.46 | khem | .deb |
| 23:22.58 | khem | 1.1.1 |
| 23:23.08 | ericben | ok so we are not far |
| 23:23.19 | ericben | is apache started ? |
| 23:23.40 | khem | nope |
| 23:23.52 | khem | same error |
| 23:24.10 | ericben | I don't see anything on http://tinderbox.openembedded.net/ |
| 23:25.07 | khem | I built a deb of django-oestats |
| 23:25.18 | khem | I built a deb of django-oestats |
| 23:25.24 | khem | <PROTECTED> |
| 23:25.29 | ericben | you installed it ? |
| 23:25.32 | khem | yes |
| 23:25.39 | ericben | ls /usr/lib/pymodules/python2.6/oestat show the files ? |
| 23:26.08 | khem | yes its populated |
| 23:26.09 | ericben | ok |
| 23:26.31 | ericben | did you restor /etc/django-oestats/tinderbox/settings.py ? |
| 23:26.53 | khem | actually nothing happened to it |
| 23:27.00 | khem | I made a copy though |
| 23:27.11 | khem | before installing django-oestats |
| 23:27.27 | ericben | can you send it to mr or pastebin it ? |
| 23:28.56 | khem | http://pastebin.com/v0kM3RNy |
| 23:30.31 | *** join/#oe GarthPS|away (~quassel@92.102.66.79) |
| 23:30.44 | *** join/#oe borg_ (~olaf@p548695BA.dip0.t-ipconnect.de) |
| 23:31.27 | ericben | ok the only difference I have here is in TEMMPLATe_DIRS : /usr/share/pyshared/oestats/templates/ |
| 23:31.54 | *** join/#oe Ainulindale (~ainu@calaquendi.org) |
| 23:32.06 | khem | ericben: why would apache fail |
| 23:33.12 | ericben | libapache2-mod-python is installed ? |
| 23:34.19 | ericben | and what says the log of apache ? |
| 23:34.44 | khem | yes I installed it again |
| 23:35.03 | ericben | at the top of settings.py, after import * I have : FORCE_SCRIPT_NAME="" |
| 23:35.05 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 23:35.13 | ericben | not sure this is needed for apache, but it was for lighttpd |
| 23:35.53 | ericben | you will need to change the myql password now it's on pastebin ;-) |
| 23:36.56 | ericben | can you send me the config file of apache ? |
| 23:37.04 | *** join/#oe mrmoku|away (~mrmoku@ppp-188-174-64-121.dynamic.mnet-online.de) |
| 23:37.04 | khem | email |
| 23:37.11 | ericben | yes |
| 23:39.19 | *** join/#oe Marex (vasum7am@u-pl1.ms.mff.cuni.cz) |
| 23:46.40 | *** join/#oe sorvats (~sorvats@201.250.156.27) |