**** BEGIN LOGGING AT Thu Apr 14 02:59:58 2011 Apr 14 05:38:59 is there any way to make all the things a recipe depends on also do_clean? Apr 14 06:20:26 gm everyone Apr 14 06:20:55 Nedlinpopo: no (unless you remove your tmp dir but then you need to build everything) Apr 14 07:43:39 hi Apr 14 07:44:59 I just saw that an openembedded-core repository poped recently on git.openembedded.org Apr 14 07:45:28 I can't find any precise information about what it is Apr 14 07:46:16 maybe someone could care to point me the right announcement ? Apr 14 07:49:51 julianpid: http://yoctoproject.org/blogs/davest/2011/yocto-project-turns-1.0 is good start Apr 14 07:50:02 thx Apr 14 07:52:26 I actually thought yocto == poky != openembedded Apr 14 07:53:17 julianpid no see it as a merge Apr 14 07:53:33 right Apr 14 07:53:37 that's good news Apr 14 07:53:43 yes Apr 14 07:53:55 and seems intel have 4-5 people working on oe-core Apr 14 07:54:00 besides rp Apr 14 07:54:03 but I'm more concerned about changes in the workflow Apr 14 07:54:16 hm which workflow? Apr 14 07:54:29 commiting patches? Apr 14 07:55:07 for example, If I have patches to submit, is it better to rebase them on oe-core, or submit them as-is as openembedded-classic diffs ? Apr 14 07:55:38 hm for now you can send it to oe-dev ml Apr 14 07:55:46 but in the future to oe-core Apr 14 07:55:52 or the distro overlay Apr 14 07:56:00 or meta-oe Apr 14 07:56:09 ah right Apr 14 07:56:15 and meta-efl in oe-dev ml Apr 14 07:56:26 will oe-classic die at some point ? Apr 14 07:56:35 jama is there now a timeplan for the oe-core/yocoto stuff Apr 14 07:56:44 julianpid I think yes Apr 14 07:57:12 one other question Apr 14 07:57:13 otherwise you are spending lot of energy to sync stuff Apr 14 07:57:18 julianpid: http://lists.linuxtogo.org/pipermail/tsc/2011-March/000209.html Apr 14 07:57:27 gm ant Apr 14 07:57:31 for me it is still unclear how things now in .dev will flow into meta-oe or oe-core (e.g. the nios2 patch I pushed last week) Apr 14 07:57:34 btw gm, all Apr 14 07:57:55 having to do/submit them twice is not an encouraging idea Apr 14 07:57:57 If I want to create a new distribution say now, is it better to take oe-core as a base, rather than the classic stuff ? Apr 14 07:58:00 morning Apr 14 07:58:18 julianpid: yes Apr 14 07:58:37 eFfeM_work: yes submit them to right layer in form of pull request Apr 14 07:59:26 eFfeM_work pull request Apr 14 07:59:52 wait, is .dev the new name for !oe-core ? Apr 14 07:59:57 JaMa: that makes that all patches submitted to .dev recently are kinda lost (which is somewhat a pity) Apr 14 08:00:17 julianpid no Apr 14 08:00:43 julianpid oe-core will only have recipes to build toolchain and sdk Apr 14 08:00:58 eFfeM_work: yes it's pity.. but if someone cares then he should resubmit those for meta-oe/meta-efl/oe-core himself (it cannot happen automagically) Apr 14 08:01:02 JaMa: woglinde: wrt the pull request, I think it would help if we would document a possible workflow, actually no idea how to publicize a git tree and not too much time to sort it out Apr 14 08:01:41 eFfeM_work: there are oe-core-contrib meta-oe-contrib repos where you can publish it Apr 14 08:01:55 eFfeM_work: and simple scripts to create and send pull request Apr 14 08:02:10 JaMa: and I do have some concerns on how pulling will be done Apr 14 08:02:27 JaMa: ah, unaware of these, don't think too much info on that has been published Apr 14 08:03:27 I agree that there is not enough info about whole oe-core/meta-oe stuff .. Apr 14 08:03:54 I'm reading tsc/poky/yocto MLs and watching commits to be able to contribute myself Apr 14 08:04:22 and all my pull requests were applied in reasonable time without any issues Apr 14 08:05:05 I gave up reading some of the lists, message overload Apr 14 08:08:50 and given the nasty remarks Koen made in TSC meetigns which were obviously hinted to me, the interest to invest time in this somewhat diminished, also partially because I have some doubts that I will get a fair treatment from him as pull master Apr 14 08:13:35 eFfeM_work koen is no pull-master at oe-core Apr 14 08:13:48 nor is he for 2011.3 maintaince branch Apr 14 08:13:49 I know I was referring to meta-oe Apr 14 08:14:07 eFfeM_work if you dont try you dont know Apr 14 08:14:17 eFfeM_work so your patches should be clean Apr 14 08:15:53 I'd hoped TSC would come up with some guidelines on how to do this effectively, I am not too eager to increase my workload further Apr 14 08:16:15 so each developer wanting to actively work should have own branch in *-contrib? Apr 14 08:16:40 the git pull model does raise the bar on the entry level Apr 14 08:16:44 for new devs Apr 14 08:18:01 it is my impression that the # of contributors and # of contributions is decreasing (but I might be misguided here) Apr 14 08:18:01 morning all Apr 14 08:18:16 hi bluelightning Apr 14 08:18:24 morning bluelightning Apr 14 08:18:42 eFfeM_work: same impression but maybe there were too many events/exhibitions in th first quarter Apr 14 08:19:17 JaMa: btw the fact that patches on .dev eventually needs to be resubmitted also give me some concerns on the usefulness of a patch weekend like stefan proposed Apr 14 08:19:26 eFfeM_work as I said intel has 5 people working on oe-core Apr 14 08:19:34 I'm off, thx for your answers guys Apr 14 08:19:51 I know, I think QA wise yocto/oe-core is a great step forward Apr 14 08:20:02 woglinde: yes, they are doing outstanding job Apr 14 08:20:14 e.g. fixing parallel build and so on Apr 14 08:20:31 eFfeM_work: most recipes are imported to meta-oe from oe.dev, and lots of recipes are still missing Apr 14 08:20:42 although I'd hoped they would focus more on the needs of developers of deeply embedded systems (like the microwave and tv in their movie) Apr 14 08:20:49 eFfeM_work: so improving them in oe.dev before import makes it better Apr 14 08:21:00 JaMa: true Apr 14 08:21:45 and after import it's usually importer job to check oe.dev for changes and sync if needed (at least I do it with recipes I've imported) Apr 14 08:22:01 JaMa: but who cares about the fresh meat in .dev? There is still to much cruft and the gems risk to be ignored Apr 14 08:22:42 I still use both.. but hope to start ignoring (and stop building) .dev soon Apr 14 08:23:04 ok, so we should say: this branch will be closed on... Apr 14 08:23:19 ant_work: 09:56:06 < JaMa> julianpid: http://lists.linuxtogo.org/pipermail/tsc/2011-March/000209.html Apr 14 08:23:55 I see, thx for the pointer Apr 14 08:23:59 bye bye .dev :-) Apr 14 08:24:14 though, such news should be big title Apr 14 08:24:42 ant_work: you dont announce the death of the previous before the next is ready Apr 14 08:24:44 let's wait for Crofton|work coming back... Apr 14 08:24:58 XorA|gone: yea, that is the actual impasse Apr 14 08:25:11 two feets in two different shoes Apr 14 08:25:14 why close the branch? if no one is using it it'll die. (and itmight be better to put it into a maintenance state) Apr 14 08:25:31 my shr-lite-images from meta-shr are usable already.. so there is no reason to wait with switch to oe-core/meta-oe and spend much time with .dev when there is bigger need to work on layers Apr 14 08:25:53 good morning Apr 14 08:25:55 hi mckoan Apr 14 08:25:56 Hi all Apr 14 08:26:01 hi mrAlmond Apr 14 08:26:02 hi mckoan Apr 14 08:26:06 :-) Apr 14 08:26:31 we could just abandon the .dev to the guys still using it, I suspect it will die pretty quick with the lack of any maintenance, but as it bitrotted to hell it would just get OE bad publicity Apr 14 08:26:47 this modern world of always wrong and always out of date wikis will see to that Apr 14 08:27:11 guys..I'm starting a brand new build with the newest yocto 1.0 Apr 14 08:27:11 XorA|gone: gosh! Apr 14 08:27:40 as it stands both meta-oe and meta-efl seem to have only3 or 4 active authors, so I am not sure if this is really accepted by the community Apr 14 08:27:53 mckoan: we were already here with familiar, its happened before Apr 14 08:28:31 XorA|gone: all this happened since yocto was created IMHO Apr 14 08:28:40 eFfeM_work: but that's not fault of those 3-4 active authors :/ Apr 14 08:30:21 * XorA|gone thinks the improvements speak for themselves, any-one too stubborn to listen is no concern of mine Apr 14 08:31:13 and with people like JaMa driving mera-oe forward so well its got a lot of momentum and a lot of real users Apr 14 08:31:44 hehe, thanks XorA|gone :) Apr 14 08:32:44 JaMa: well you do drive one of the success stories of OE Apr 14 08:32:46 note I am not against meta-oe, but I feel getting the community involved is important; forcing them to become involved by shutting .dev might drive some away Apr 14 08:33:40 eFfeM_work you are thinking to much Apr 14 08:34:02 maybe Apr 14 08:35:34 JaMa: BTW are you guys all tooled up with gta04 devices these days? Apr 14 08:37:19 XorA|gone: nope, but we got few n900 Apr 14 08:37:59 JaMa: wish I had known about gta04 before I gave away all my phones, Id have kept one case/screen Apr 14 08:40:19 XorA|gone: don't know if I'll buy gta04 for myself as I really like hw keyboard on phone Apr 14 08:40:37 XorA|gone: much better to debug Xorg when it dies often :) Apr 14 08:42:38 JaMa: hehe Apr 14 08:44:08 gta0x case is not userfriendly Apr 14 08:44:28 beside that, what's happening to th eminimal distro? I see layers for angstrom and shr but not for that Apr 14 08:44:29 hi hrw Apr 14 08:55:16 where does the shr layer live? Apr 14 08:59:07 eFfeM_work: http://git.shr-project.org/git/?p=meta-shr.git;a=summary for now Apr 14 08:59:21 ah ok, thanks Apr 14 08:59:33 then I see branches in -contrib Apr 14 09:00:18 ant_work: shr branches in -contrib? that's my patch queue used in shr already Apr 14 09:00:55 ant_work: shr is using Makefile to checkout all needed repos and create configs (like oebb.sh script does for Angstrom) Apr 14 09:01:35 ant_work: and shr branches are used to be able to push some ie oe-core patch sooner then it's applied from pull request or when it's controversial but we really need it Apr 14 09:01:41 those are exactly the obscure points, I need to document myself Apr 14 09:01:55 so each distro will need a layer and some branches? Apr 14 09:02:12 no in ideal world Apr 14 09:02:33 I hope to use them only to track master without own patches later Apr 14 09:02:39 ok, I only see poky distro included in oe-core. will be hopefully renamed Apr 14 09:02:53 or abandon them later at all and use master branches directly again Apr 14 09:03:06 a, I see Apr 14 09:03:19 ant_work: read tsc minutes/lists.. it should be removed from oe-core repo Apr 14 09:03:43 I missed th etsc ML... still reading all the others ;) Apr 14 09:03:53 I think it creates great load of confusion.. meta-poky would be much better Apr 14 09:04:27 ant_work: buy new keyboard :) Apr 14 09:04:34 morning Apr 14 09:04:35 he he Apr 14 09:04:47 space key is almost floating :) Apr 14 09:05:16 mrAlmond: check this pull request [OE-core] [v2 00/12] [v2] recipe upgrades and fix Apr 14 09:13:15 hi mickeyl Apr 14 09:13:18 hi , i need some microwave reflector that i ll focus it by a computer program some location.any programmable reflector do you know like that ? Apr 14 09:17:36 JaMa: I think the challenge is in figuring out what parts of poky to keep/rename/change so that they fit into oe-core Apr 14 09:18:31 bluelightning: agreed, I hope that f2f meeting on elc was spend well on this topic :) Apr 14 09:18:55 JaMa: yes I am looking forward to an update from the participants about what was discussed Apr 14 09:20:36 all proposed topics http://lists.linuxtogo.org/pipermail/tsc/2011-April/000225.html are obviously important to me :) Apr 14 09:22:30 JaMa: about layers/overlays...wouldn't Gentoo's layman be a good start? Apr 14 09:24:27 ant_work: not sure.. because Gentoo's layer are much more independent then oe layers Apr 14 09:24:55 ant_work: iirc layman doesn't care at all about layer relations Apr 14 09:26:05 ant_work: so layman -L is all what I find usable currently for oe and that could be implemented by simple wiki page Apr 14 09:26:26 well, from the beginning Apr 14 09:26:27 Layman uses a central list of overlays in XML format Apr 14 09:26:38 can we agree with that or not? Apr 14 09:26:44 yes Apr 14 09:26:55 but who would maintain such list? Apr 14 09:27:21 see e.g. http://gpo.zugaina.org/Overlays Apr 14 09:29:20 ant_work: but greatest benefit of layman from my POV is unified checkout (doesn't matter if it's svn or git repo etc) and automatic update with sync Apr 14 09:29:51 yes, one fetcher Apr 14 09:30:04 ant_work: but for oe it's more complicated as I would expect that some layers are intended to be used only with some version of other layers etc Apr 14 09:30:20 btw Currently layman supports overlays that are exported via rsync, subversion, bzr, darcs, git, mercurial or provided as tar packages. Apr 14 09:30:29 in gentoo layers you usually use just latest from all and it's supposed to work Apr 14 09:30:35 he he Apr 14 09:31:03 and maintaining overlays list in make.conf is quite the same as bblayers.conf Apr 14 09:31:20 I think that adding some logic would not be a terrible job for our python specialists Apr 14 09:31:45 JaMa: in the end you build the right string Apr 14 09:32:02 is very comparable process like oebb Apr 14 09:32:25 my point is, that for oe build it's quite dangerous to just layman -a some-layer-with-something-usefull Apr 14 09:32:52 'universe' is dangerous too :p Apr 14 09:33:31 and oebb is very carefully prepared so it does right job.. on the oposite average oe builder will just layman -a everything and then complain that something stopped working Apr 14 09:33:50 we have to live with the idea different people have different needs Apr 14 09:33:58 devs usually know what theyare doing Apr 14 09:34:00 isn't? Apr 14 09:34:04 :P Apr 14 09:34:16 it's already hard enough to describe how to reproduce faulty built of something Apr 14 09:35:06 ant_work: because their read layer README and check layer tree before adding it Apr 14 09:35:20 ant_work: that's something even smart python script won't do for you IMHO Apr 14 09:35:30 JaMa: web is full of broken Gentoo's layered installation but there are also many working... Apr 14 09:35:38 you start with sane default, ofc Apr 14 09:36:05 for me.. share one wiki page with checkout urls and README for all layers Apr 14 09:36:13 imho adding a local layer hould be straightforward Apr 14 09:36:22 * ant_work kicks keyboard Apr 14 09:36:45 then I'll update bbappend manually when I found something really usefull there Apr 14 09:37:09 right Apr 14 09:37:20 * Jay7 fears repo-hell coming Apr 14 09:37:57 jay7 like android? Apr 14 09:38:52 I'm not familiar with android.. Apr 14 09:39:22 JaMa: about oe-core, I've seen some recipes are almost like in oe-dev but lack the /$DISTRO or /$MACHINE override in FILES. Are those supposed to go to th elayer, isn't? Apr 14 09:39:32 I like ArchLinux - here is single open repo for submission Apr 14 09:39:34 (see udev and angstrom mount script) Apr 14 09:39:38 I mean AUR Apr 14 09:41:12 JaMa: same case for the overrides in the recipes, those need to be purged out before going to oe-core Apr 14 09:41:48 ant_work: right Apr 14 09:44:12 hi, i am using Angstrom on Beagleboard, while i was upgrading, i ended up an error: this is very bad.Enlightenment SEGV'd. This is not meant to happen and is likely a sign of a bug in Enlightenment or the libraries it relies on.You can gdp attach to this process now to try debug it or you could exit, or just hit restart to try and get your desktop back the way it was. please compile eveything with -g in your CFLAGS. Apr 14 09:44:28 JaMa: do you halready have an idea about how to build a Zaurus layer with all the overrides ? Apr 14 09:44:30 what solud i do? Apr 14 09:44:49 what should i do? Apr 14 09:45:16 ant_work: yes you do the modification in .bbappend files Apr 14 09:47:00 how can i solve the Enligtenment problem? Apr 14 09:47:57 I'm getting errors when building Angström: NOTE: package m4-native-1.4.14-r0.1: task do_compile: Failed Apr 14 09:48:27 From the logfile I have Apr 14 09:48:28 | make: GNUmakefile: Too many levels of symbolic links Apr 14 09:48:28 | make: stat: GNUmakefile: Too many levels of symbolic links Apr 14 09:48:28 | make: *** No rule to make target `GNUmakefile'. Stop. Apr 14 09:48:52 Svendsen use pastebin Apr 14 09:48:57 ~pastebin Apr 14 09:48:57 [~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude. Apr 14 09:49:23 Svendsen: don't use symlinks for tmpdir/workdir or whatever Apr 14 09:49:32 Svendsen: use mount --bind if needed Apr 14 09:52:26 i am using Angstrom on Beagleboard, while i was upgrading, i ended up an error: this is very bad.Enlightenment SEGV'd. This is not meant to happen and is likely a sign of a bug in Enlightenment or the libraries it relies on.You can gdp attach to this process now to try debug it or you could exit, or just hit restart to try and get your desktop back the way it was. please compile eveything with -g in your CFLAGS. Apr 14 09:53:24 neco: follow the advice Apr 14 09:53:30 ok Apr 14 09:53:32 http://pastebin.com/UmqxfjMX Apr 14 09:53:33 neco repeating stuff dont get your further Apr 14 09:53:58 JaMa: btw koen just did s/-o sync/-o async,relatime/1 to the mount scripts. Maybe this can go in oe-core Apr 14 09:54:18 JaMa: btw btw udev in oe-core has still flies for Zaurus :p Apr 14 09:54:26 Svendsen follow the advice from jama Apr 14 09:55:49 ant_work: many machine/distro files/overrides are not strictly out-of-the-oe-core Apr 14 09:56:12 hm... how is that? Apr 14 09:56:23 jama hm Apr 14 09:56:41 OK, thanks I'll try in a path witout symbolic links Apr 14 09:57:20 ant_work: I guess that's side-effect from incremental changes with starting point similar to oe.dev is now Apr 14 09:57:52 all fine if this will be cleaned Apr 14 09:58:11 (we don't need those bogus overrides) Apr 14 09:58:21 and to be honest, I found it more difficult to clean it from oe-core just to .bbappend it in next layer Apr 14 09:58:42 I try to understand where my sandbox is... Apr 14 09:58:43 cause you have to keep next_layer in since with oe-core then Apr 14 09:59:46 ant_work: small example http://git.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-support/libusb/libusb-compat_0.1.3.bbappend is completelly valid Apr 14 10:00:04 ant_work: but having those 4 lines in oe-core recipe won't harm much Apr 14 10:00:24 ant_work: and it would be easier to find/update Apr 14 10:01:01 ant_work: now when oe-core introduces libusb-compat_0.1.4 we have to add libusb-compat_0.1.4.bbappend immediately to meta-oe or build will fail Apr 14 10:01:17 yea, critic example :) Apr 14 10:02:29 but the same is with ie machine specific config file in SRC_URI Apr 14 10:02:53 new version is added to oe-core.. you won't notice while building with some machine-layer Apr 14 10:03:03 bad package is created and installed on device Apr 14 10:03:29 you have to update machine-layer and bump PR to get new fixed package on device Apr 14 10:03:45 then upstream bumps PR and you're out of luck Apr 14 10:04:02 IMHO things like libusb shouldnt be in OE core Apr 14 10:04:05 and won't get those changes from PR bump Apr 14 10:04:24 on device.. Apr 14 10:04:57 * JaMa lunch Apr 14 10:05:08 and should work.. Apr 14 10:15:03 I have a problem with yocto 1.0 starting a new build, this is the bb log : Apr 14 10:15:25 Pseudo is not present but is required, building this first before the main build Apr 14 10:15:25 Exception in thread Thread-2: | ETA: --:--:-- Apr 14 10:15:25 Traceback (most recent call last): Apr 14 10:15:31 self.__target(*self.__args, **self.__kwargs) Apr 14 10:15:33 File "/usr/lib/python2.6/multiprocessing/pool.py", line 259, in _handle_results Apr 14 10:15:35 task = get() Apr 14 10:15:37 TypeError: ('__init__() takes exactly 2 arguments (51 given)', , ('$', '{', 'E', '_', 'S', 'V', 'N', '}', '/', 't', 'r', 'u', 'n', 'k', ';', 'm', 'o', 'd', 'u', 'l', 'e', '=', 'e', 'd', 'j', 'e', ';', 'p', 'r', 'o', 't', 'o', '=', 'h', 't', 't', 'p', ';', 's', 'c', 'm', 'd', 'a', 't', 'a', '=', 'k', 'e', 'e', 'p')) Apr 14 10:15:52 mrAlmond_ please use pastebin Apr 14 10:15:56 ~pastebin Apr 14 10:15:56 [~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude. Apr 14 10:16:06 you are right Apr 14 10:16:07 sorry Apr 14 10:17:42 http://pastebin.com/1VdDMrpA Apr 14 10:18:10 mrAlmond_: check if you have this commit http://git.openembedded.org/cgit.cgi/openembedded-core/commit/?id=66e6837b536859bcf940380cfcdf50670790d889 Apr 14 10:19:39 No I'haven't that one Apr 14 10:19:47 I'm merging diffs Apr 14 10:19:49 tnx! Apr 14 10:20:02 then you have to apply manually or just start using oe-core HEAD instead of yocto release Apr 14 10:20:59 yes..I've applyed it manually and now the build started :-) Apr 14 10:34:47 hi, Xorg says: Apr 14 10:34:49 Backtrace: Apr 14 10:34:53 Floating point exception at address 0x2f5 Apr 14 10:35:07 should I debug that the usual way(gdb+gdbserver) Apr 14 10:35:17 or is there any better way Apr 14 10:58:29 libxft-native recipe is missing in yocto 1.0 Apr 14 10:59:28 must add BBCLASSEXTEND = "native nativesdk" ? Apr 14 10:59:51 to libxft_2.2.0.bb Apr 14 11:03:07 mrAlmond_: yes, or apply http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/commit/?h=shr&id=10c047dea47eac732666ef0b62ca0b509301ec2f Apr 14 11:03:36 doh! I didn't check that repository... Apr 14 11:04:01 what's the difference between oe-core and oe-core-contrib ? Apr 14 11:04:33 contrib are for people to contribute and send pull requests from Apr 14 11:05:35 ok Apr 14 11:12:51 does yocto automatically uses multiple make jobs when multi core processors are available? Apr 14 11:22:00 afaik no you have to set it in local.conf Apr 14 11:31:29 JaMa, was Xorg upgraded recently? Apr 14 11:31:41 where? Apr 14 11:32:27 GNUtoo: oe.dev still has 1.9.4 as default xserver, meta-oe 1.10.0.90[12] Apr 14 11:32:48 GNUtoo: and couple of xorg recipes were upgraded too Apr 14 11:32:48 ok, I'm still using oe.dev Apr 14 11:33:02 I've that now on angstrom2010 oe.dev bug20: Apr 14 11:33:07 Backtrace: Apr 14 11:33:07 [1412811.024] Floating point exception at address 0x2f5 Apr 14 11:33:17 Xorg.log Apr 14 11:33:27 GNUtoo: http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=a39e33b7a508849a6dffe577370d7a80fbf26511 Apr 14 11:35:05 it's DP -1 Apr 14 11:36:24 that's why I said 1.9.4 is default.. but maybe it's libx11 fault, that's why I'm showing this commit Apr 14 11:38:35 ok Apr 14 11:38:44 gdb didn't work Apr 14 11:38:48 trough wifi Apr 14 11:39:05 usbnet doesn't work on that device Apr 14 11:39:09 I'll try ethernet Apr 14 11:46:08 I'll try using the LCD module Apr 14 11:48:21 hmmm it work using the LCD module Apr 14 12:14:29 hej, just to get things right: is git://git.angstrom-distribution.org/meta-texasinstruments the "official" beagleboard layer that should be used in the new layout ? Apr 14 12:16:14 thank you JaMa now I've enabled the quad core support in local.conf :-) Apr 14 12:26:22 mlip: yes Apr 14 12:27:00 urg Apr 14 12:27:05 he crofotn Apr 14 12:27:24 almost 3 hours of sleep Apr 14 12:28:10 hehe Apr 14 12:28:15 dont drink this much Apr 14 12:31:20 heh Apr 14 12:31:26 red eye back from the left coast Apr 14 12:31:41 left at 0020 and arrived at 0730 or so Apr 14 12:41:13 Those are flights for younger people than I -- I can't do those anymore. :) Apr 14 12:44:55 I'm not sure I can Apr 14 12:45:15 two jackasses across from me had a loud conversation for an hour or so into the flight Apr 14 12:45:55 crofton you should have kicked them out Apr 14 12:46:43 that would have been fun Apr 14 12:47:17 people can be quite inconsiderate on aircraft... not a good thing considering everyone else is probably in a bad mood :/ Apr 14 12:48:05 mlip: are you Michael Lippautz ? Apr 14 12:48:27 especially at 0100 ..... Apr 14 12:48:37 JaMa, yes, I did the prefix wrong... anything, else? Apr 14 12:48:38 and everyone else wants to sleep Apr 14 12:49:05 mlip: why do you take it from oe.dev when it's in better form in meta-oe? Apr 14 12:49:28 I wonder if there is a way for recipes to add build machine checks Apr 14 12:49:46 JaMa, it is ? i have meta-oe in my list ... Apr 14 12:50:01 for example, some of the ti-* recipes need 32 bit glibc on the build machine Apr 14 12:50:09 this may be related to my bblayers ordering (once, more) ? Apr 14 12:50:16 mlip: http://git.openembedded.org/cgit.cgi/meta-openembedded/commit/?id=89500c583e0f1dc1b4ffdf72914e08e505e427e0 Apr 14 12:50:55 mlip: if you use poky then old version is locked by prefered-xorg-versions.inc Apr 14 12:51:15 JaMa: I use oe-core, oe-meta and meta-angstrom Apr 14 12:51:26 it is pinned in oe-core i think Apr 14 12:53:06 JaMa, it's pinned in oe-core, should this change then, or is it up to the user to add a pref. version? (or distro?) Apr 14 12:53:17 don't know about angstrom, but I don't include that prefered-xorg-versions.inc in shr distro.. just because it's stupid wrt multiple layers.. Apr 14 12:54:26 mlip: conf/distro/include/angstrom-2010-preferred-versions.inc:require conf/distro/include/preferred-xorg-versions-live.inc Apr 14 12:54:28 JaMa, angstrom has it's preferred-xorg-versions-live.inc Apr 14 12:55:06 JaMa, i see yeah, but actually then I don't know where it should be pinned Apr 14 12:55:36 just remove this line Apr 14 12:56:25 JaMa, then oe-core is in charge and pins it to 1.11.0 ?, so I would have to alter two layers Apr 14 12:57:10 no, poky's prefered-xorg-versions.inc will not be included for angstrom Apr 14 12:57:37 ah right, since it's named different Apr 14 12:57:47 and hopefully will be moved to meta-poky or whatever soon Apr 14 12:58:49 yeah that would make some sense, it's just hard to get which layer is responsible for what Apr 14 15:11:31 Guys...I'm getting configure error "error: possibly undefined macro: AM_GCONF_SOURCE_2" in gnome-vfs-native... Apr 14 15:11:45 is there a fix for this? Apr 14 15:12:13 I've tried to install gconf-native but it was already installed Apr 14 16:22:52 huh. python-debian parses .ipk files just fine. i wonder if opkg-utils's opkg.py should just go away in favor of using debian's python modules to do stuff Apr 14 16:23:00 heh Apr 14 16:23:32 hehe Apr 14 16:23:34 lol Apr 14 16:25:47 it provides parsing of dependency strings too, even has an example script to generate graphviz from the deps.. Apr 14 16:25:48 heh Apr 14 16:27:34 honestly, .ipk's file format doesn't provide anything at all above .deb, so i'm not seeing the point. maybe we should think about a rewrite just working with .deb :P Apr 14 16:28:12 just using debs would be good Apr 14 16:28:31 we only really need to replace the *tool*, not the formats Apr 14 16:30:48 can anyone please help.? i am new to oe.. and on my first hello world ..i am getting this error Apr 14 16:30:51 http://pastebin.com/dhaDjp9B Apr 14 16:30:51 i wonder how much of apt's behavior is in apt itself vs the apt libraries Apr 14 16:31:37 pooja: that would be a 404. upstream removed the patch on us Apr 14 16:32:17 so what should i do.? Apr 14 16:32:24 this is my first time on oe.. Apr 14 16:32:26 :P Apr 14 16:33:34 and the problem isn't directly related to oe. oe downloads a file from somewhere. that somewhere removed it. what would you do if that was the case outside of OE? I'm betting google for the file, try to find it on a mirror. the same is true here, except that you could also try oe's mirrors. what DISTRO are you using? Apr 14 16:33:58 you could try using angstrom's mirrors, you can do that simply by setting INHERIT += "angstrom-mirrors" Apr 14 16:34:01 see if that helps Apr 14 16:34:03 kergoth is it ncurses again? Apr 14 16:34:08 looks that way Apr 14 16:34:18 we need to stop relying so much on upstreams Apr 14 16:34:18 hm koen fixed it Apr 14 16:34:29 ah, maybe pooja just needs to update? or upstream sucks Apr 14 16:34:30 :) Apr 14 16:34:46 fetch failures must bite us in the ass on a weekly basis Apr 14 16:34:49 hm with .dev he wouldnt hit it anyway Apr 14 16:35:00 ah Apr 14 16:35:00 because of ncurses 5.9 Apr 14 16:35:10 right, forgot about that Apr 14 16:35:16 angstrom mirrors wont help with that ncurses problem Apr 14 16:35:19 * kergoth points pooja at woglinde and steps back Apr 14 16:35:27 l2g apache is set not to transmit .sh files Apr 14 16:35:39 oh really? huh Apr 14 16:35:47 yes Apr 14 16:35:55 weird. Apr 14 16:36:14 florian should have installed lightty ages ago Apr 14 16:36:29 wel m using metano.. Apr 14 16:36:34 what? Apr 14 16:36:51 disto .. metano Apr 14 16:37:02 ah hm Apr 14 16:37:12 seems you are the one since ages using that Apr 14 16:37:41 this is my first time. Apr 14 16:37:45 try angstroem Apr 14 16:38:20 actually i hav been askd to use metano Apr 14 16:38:30 uhm? Apr 14 16:38:45 * XorA|gone has never even heard of metano :-) Apr 14 16:39:01 :P Apr 14 16:41:21 whats it for? Apr 14 16:42:19 ..? Apr 14 16:45:26 how are the mirrors chngd,..? Apr 14 16:45:36 i mean in which file i got to modify Apr 14 16:48:34 so metano is either an Italian Car or the Gas given off by Cows... Apr 14 16:59:35 hehe! Apr 14 17:41:25 hi stefan Apr 14 17:41:34 hi woglinde Apr 14 17:41:37 hi all Apr 14 17:42:20 stefan_schmidt, morning...is patchwork back to normal yet? Apr 14 17:42:38 ka6sox-away: did it have problems? Apr 14 17:43:05 yes, it choked on a HUGE patch. Apr 14 17:43:15 oh Apr 14 17:43:25 ka6sox-away: patches or patchwork installation? Apr 14 17:43:39 ah, must be patchwork as the old one does not get new patches :) Apr 14 17:43:45 right Apr 14 17:43:47 new one Apr 14 17:44:16 ka6sox-away: haven't tested it during the last days Apr 14 17:44:30 And at the weekend I only need to old one anyway Apr 14 17:44:33 I spoke to the kernel.org guy who runs his...it takes some "managing" Apr 14 17:45:06 I guess we could add some logic that rejects patches that are too long... Apr 14 17:45:15 ok Apr 14 17:45:51 but a better way would be to have policies like kernel.org does about how patches are submitted and what they should look like. Apr 14 17:46:14 ka6sox-away: hmm, ok Apr 14 17:46:19 * khem yawns Apr 14 17:46:24 such as more atomic patches. Apr 14 17:46:27 ka6sox-away: was it just the sie of the patch or also some malformatting? Apr 14 17:46:33 hi khem Apr 14 17:46:38 hi Apr 14 17:46:42 khem might know better Apr 14 17:46:53 whats up Apr 14 17:46:55 khem, you didn't mention that hopsnbarley was the one you were meeting. Apr 14 17:47:19 ka6sox-away: I did I thought Apr 14 17:47:33 and we were so late Apr 14 17:47:46 he called me but I was already heading south. Apr 14 17:47:48 since he came at 4 and sessions got over by 5:30 Apr 14 17:47:55 ah right Apr 14 17:48:23 khem, why did the TS7500 patch fail? size or formatting? Apr 14 17:48:26 stefan_schmidt: pw should be all now Apr 14 17:48:40 khem: ok Apr 14 17:48:42 ka6sox-away: it had serious long lines Apr 14 17:48:56 that pw mail parser tripped on Apr 14 17:49:06 khem: maybe we could adjust the oe-core patch submitting guidelines to cover that as well Apr 14 17:49:10 atleast thats what I figured Apr 14 17:49:10 okay so formatting. Apr 14 17:49:17 I would think fray would be happy about that :) Apr 14 17:49:30 stefan_schmidt: I will fix the parser to reject crap Apr 14 17:49:47 khem: ok, sounds good Apr 14 17:49:52 and probably send a slapstick back to author if possible Apr 14 17:50:01 khem: btw, you got an efika mx, right? Smarttop or smartbook? Apr 14 17:50:09 smarttop Apr 14 17:50:17 its amazing box Apr 14 17:50:21 stefan_schmidt, sounds like maybe the oe-core submitting guidelines are a good idea. Apr 14 17:50:46 khem: yeah, I have both here now. The smartbook is pretty neat. Finally an ARM netbook. And even ubuntu as default :) Apr 14 17:51:00 stefan_schmidt: I wish I had a smartbook Apr 14 17:51:09 ka6sox-away: I will try to remember putting this up with fray in the next TSC meeting Apr 14 17:51:11 yep Apr 14 17:51:15 anyone used qt4-embedded on an n900? Apr 14 17:51:19 khem: maybe just ask genesi? Apr 14 17:51:22 stefan_schmidt: did u buy the sb Apr 14 17:51:35 mickeyl: I have used it on efika-mx Apr 14 17:51:36 khem buy an ac100 Apr 14 17:51:46 khem: got both from genesi, after they forgot to sent be stuff for about 6 months :) Apr 14 17:51:48 only 190 euros Apr 14 17:52:02 khem: does it work with your touchscreen? i get unknown mouse event type=3, code=18, value=7c Apr 14 17:52:09 woglinde: in europe Apr 14 17:52:12 woglinde: ac100 is nice has tegra on i Apr 14 17:52:24 mickeyl: I dont have touchscreen Apr 14 17:52:29 hmm, k Apr 14 17:53:02 woglinde: can it run real OS also Apr 14 17:53:05 yes Apr 14 17:53:08 besides android Apr 14 17:53:12 but without sound for now Apr 14 17:53:17 hmm Apr 14 17:53:17 hm ha Apr 14 17:53:22 has sound now Apr 14 17:53:32 but nut with .37 kernel Apr 14 17:53:35 not Apr 14 17:54:02 hmm Apr 14 17:54:09 tslib doesn't work either Apr 14 17:54:13 "selected device is not a touchscreen I understand" Apr 14 17:54:24 mickeyl you are using shr? Apr 14 17:54:38 no Apr 14 17:54:52 custom console image Apr 14 17:54:54 woglinde: seems its hackable Apr 14 17:55:04 and they seem to have freenode channel too Apr 14 17:55:19 khem hehe yes Apr 14 17:55:20 http://tosh-ac100.wetpaint.com/page/rooting Apr 14 17:55:23 I am there Apr 14 17:55:56 ah Apr 14 17:56:00 make oe work on it then Apr 14 17:56:22 I did Apr 14 17:56:27 wow :) Apr 14 17:56:29 thats neat Apr 14 17:56:31 kernel recipe could need an update Apr 14 17:58:45 hmm I wonder if they are selling it in us yer Apr 14 17:59:25 khem not really but price dropped here 200 euros in less than 6 month Apr 14 18:00:22 woglinde: they dont sell those AC100 on US :( Apr 14 18:00:32 something US folks can buy when in EU Apr 14 18:00:54 khem I could buy you one Apr 14 18:01:00 with german layout Apr 14 18:01:06 ;) Apr 14 18:01:20 yeah y and z transposed Apr 14 18:03:36 Efikmx sb is 199 USD Apr 14 18:12:01 stefan_schmidt: I have smarttop :) Apr 14 18:12:20 Jay7: :) Apr 14 18:12:55 still haven't tried OE images on it Apr 14 18:38:03 hello... I hope someone can help me... I'm Italian so sorry for my english... I have a problem: I'm not an expert in OE but I have to use it to develop an application for my thesis and I have the following problem... last week i had to format my Ubuntu partition and I did a backup of my OE folder that worked perfectly... Now I replaced it on my new system but I have the following problems: Apr 14 18:39:27 the temp/cross folder is empty (I don't know why) so the system, everytime i try to bitbake helloword (for example) tell me: Apr 14 18:39:28 arm-angstrom-linux-gnueabi-gcc: No such file or directory Apr 14 18:40:00 ok... so, from another backup i replaced the folder tmp/cross and now i have the following error: Apr 14 18:40:14 ../../arm-angstrom-linux-gnueabi/bin/ld: cannot find -lgcc_s Apr 14 18:40:28 someone can help me to fix this problem? Apr 14 18:42:12 someone is here? Apr 14 18:42:32 is here someone? Apr 14 18:43:46 gilby85, since you are building angstrom have you asked in #angstrom? Apr 14 18:44:42 i know but the problem is related to OE because i found on google many questions like mine related to other OE distributions Apr 14 18:45:00 the problem is the compiler, not something strictly related to angstrom Apr 14 18:47:05 03Jeff Lance  07master * rf74f457881 10openembedded.git/recipes/ti/ (3 files): Apr 14 18:47:05 matrix-gui: Bump up SRCREV Apr 14 18:47:05 * Bump up SRCREV Apr 14 18:47:05 * add am389x platform support Apr 14 18:47:05 * am1808 add correct instructions for running profibus demo Apr 14 18:47:06 Signed-off-by: Jeff Lance Apr 14 18:47:06 Signed-off-by: Denys Dmytriyenko Apr 14 18:50:10 03Siddharth Heroor  07master * r0da70845a3 10openembedded.git/recipes/ti/ti-ipc_1.22.05.27.bb: Apr 14 18:50:10 ti-ipc: Add version 1.22.05.27 Apr 14 18:50:10 Signed-off-by: Siddharth Heroor Apr 14 18:50:10 Acked-by: Chase Maupin Apr 14 18:50:10 Signed-off-by: Denys Dmytriyenko Apr 14 18:53:14 is there someone who can help me? Apr 14 18:58:45 03Siddharth Heroor  07master * r4ee4db2d49 10openembedded.git/recipes/powervr-drivers/omap3-sgx-modules_1.6.16.3977.bb: Apr 14 18:58:45 omap3-sgx-modules: Update TI816x Module Location and Platform variables. Apr 14 18:58:45 * With Graphics SDK 4.03.00.02, TI816x module location and platform Apr 14 18:58:45 has been made more generic - ti81xx. This is to support TI814x Apr 14 18:58:45 which uses exactly the same SGX core as TI816x. Apr 14 18:58:46 Signed-off-by: Siddharth Heroor Apr 14 18:58:47 Signed-off-by: Denys Dmytriyenko Apr 14 18:58:48 03Siddharth Heroor  07master * r1ef00c5be5 10openembedded.git/recipes/powervr-drivers/libgles-omap3_4.03.00.02.bb: Apr 14 18:58:48 libgles-omap3: Correct libraries for TI816x. Apr 14 18:58:48 * Explicitly set ES6LOCATION. Apr 14 18:58:49 * Split OMAP3 and TI816x BINLOCATION. TI816x uses ES6.x libraries. Apr 14 18:58:49 Signed-off-by: Siddharth Heroor Apr 14 18:58:50 Signed-off-by: Denys Dmytriyenko Apr 14 18:58:54 03Siddharth Heroor  07master * rb326d2d7ff 10openembedded.git/recipes/powervr-drivers/libgles-omap3/rc.pvr: Apr 14 18:58:54 libgles-omap3: Remove SGX Fixup for TI816x. Apr 14 18:58:54 * Unlike OMAP3, the SGX core has not undergone revisions in TI816x. Apr 14 18:58:54 The libraries for TI816x are also fixed and do not need fixup based Apr 14 18:58:55 on revision of the SGX core. Apr 14 18:58:55 Signed-off-by: Siddharth Heroor Apr 14 20:33:22 khem you about? Apr 14 20:39:25 ka6sox-away: yes Apr 14 20:39:46 but gotta go to give a ride to my wife her car broke Apr 14 20:40:04 gilby85: you need to rebuild from scrath Apr 14 20:40:15 13:37 -!- lamawithonel ~lucas@pool-96-240-135-33.washdc.fios.verizon.net has quit [Ping timeout: 240 Apr 14 20:40:18 seconds] Apr 14 20:40:21 13:37 -!- lamawithonel ~lucas@pool-96-240-135-33.washdc.fios.verizon.net has joined #oe Apr 14 20:40:24 13:38 < khem> ka6sox-away: yes Apr 14 20:40:27 13:39 < khem> but gotta go to give a ride to my wife her car broke Apr 14 20:40:29 13:39 < khem> gilby85: you need to rebuild from scrath Apr 14 20:40:32 [khem(+Zi)] [6:#oe(+t)] Apr 14 20:42:11 khem? Apr 14 20:43:15 uh oh Apr 14 20:43:26 khem, cu in a bit. Apr 14 20:43:49 woglinde_, now to see if we can speed up the builds... Apr 14 20:43:58 what? Apr 14 20:44:13 we have a raid0 of 2 SSDs...611MB/Sec writes random. Apr 14 20:44:23 hm ah Apr 14 20:44:28 with trim filesystem? Apr 14 20:44:49 ext2 to start...then I'll look into something with trim. Apr 14 20:45:01 ieeehlks Apr 14 20:45:04 ext2? Apr 14 20:45:10 what the hell Apr 14 20:45:11 reference. Apr 14 20:45:18 don't care about journaling Apr 14 20:45:26 its a scratch space to build in. Apr 14 20:46:13 its not journaling only Apr 14 20:46:14 trim Apr 14 20:46:25 you can use ext4 without journal Apr 14 20:47:33 cat /proc/filesystems. Apr 14 20:47:33 ugh Apr 14 20:47:33 sorry Apr 14 20:47:55 o.O Apr 14 20:48:01 ah Apr 14 20:48:22 just seeing if the autobuilder supports that filesystem in the kernel. Apr 14 20:48:37 hm which kernel runs? Apr 14 20:50:52 2.6.32 Apr 14 20:53:47 okay so no trim Apr 14 21:05:11 woglinde_, likely the raid controller couldnt' handle that anyways. Apr 14 21:05:20 hm oh Apr 14 21:05:22 okay so rm_work is in.... Apr 14 21:05:36 I can wipe it out @ 12.7G/sec Apr 14 21:08:20 wuaha Apr 14 21:09:31 woglinde_, its just the file allocation bits. Apr 14 21:09:33 so its fast. Apr 14 21:09:43 okay good nite Apr 14 21:09:48 niters! Apr 14 21:10:06 maybee tomorrow I will make backup here and switch some partitions tom ext4 Apr 14 21:20:09 hm.. I should check speed of wipeing on RAID0 + ext4 ;) Apr 14 21:23:03 we wiped a 150GB file on ext2, RAID0 of 2 SSD's in a touch under 12 seconds during our tests Apr 14 21:23:55 hiya Jay7 great time @ ELC...got a lot accomplished. Apr 14 21:24:18 ka6sox-away: btw, how it was? :) Apr 14 21:24:37 very good..I enjoyed a lot of the talks. Apr 14 21:24:47 met with pidge and got things going there. Apr 14 21:24:53 learning twisted. Apr 14 21:25:02 hehe Apr 14 21:26:55 working on adding the things I care about to buildstats. Apr 14 21:27:36 Jay7, cryptk ran bonnie 8X and worst we saw was 200-300MB/sec writes on random filesizes. Apr 14 21:28:15 I literally gave it the worst possible torture test that I could possibly come up with Apr 14 21:28:26 your builder will never be able to hammer those disks as hard as I did Apr 14 21:28:40 um...yes it will. Apr 14 21:29:01 but because of no rotational latency thrashing will be less. Apr 14 21:29:03 500,000 blocks written per second Apr 14 21:29:13 I doubt it, but we will see Apr 14 21:29:17 OE, I challenge you Apr 14 21:29:23 uh oh... Apr 14 21:29:23 lol Apr 14 21:29:37 hehe.. let's place there mysql and re-enable oe-stats ;) Apr 14 21:38:06 Jay7, I am going to work on enhancing buildstats that yocto is using. Apr 14 21:38:18 ka6sox-away: nice :) Apr 14 21:38:22 keep me informed Apr 14 21:38:29 do you have any plan? Apr 14 21:38:52 start with what pidge is using and add necessary bits. Apr 14 21:39:24 have to rework the informer bits from BB but that was going to have to change anyways as it doesn't scale. Apr 14 21:41:48 for now pass/fail and fail log from fail. Apr 14 21:42:17 and some usage stats on disk/mem/cpu Apr 14 21:52:44 ah...that udev recipe.... Apr 14 21:57:43 mwester, how big is a full slugOS build? Apr 14 22:01:55 after a full build completes, and rm_work does its work, the tmpdir is about 16GB or so. Apr 14 22:02:25 how about without rm_work. Apr 14 22:02:32 just so I can see max sized. Apr 14 22:02:47 du is still running on that box. Apr 14 22:02:52 kk Apr 14 22:06:17 21 GB for the downloads directory Apr 14 22:06:38 okay how much scratch space? Apr 14 22:06:51 Still waiting for that final du to finish! Apr 14 22:06:56 ie your /tmp dir Apr 14 22:07:04 Yep. It's HUGE. Apr 14 22:07:18 And that's without building any of the X libs and software, yet. Apr 14 22:07:48 or boost or qt Apr 14 22:08:01 It does have boost, but not qt Apr 14 22:08:38 that needs like 3G of RAM to link iirc. Apr 14 22:08:38 And then add 1GB or so additional for each of qemuarm and sheevaplug variants. Apr 14 22:08:46 Yep. Apr 14 22:09:52 There are a few HUGE link steps that force my autobuilder to run with -j 1, else it occasiionally borks my mythtv stuff which is on the same server. Apr 14 22:10:03 Still waiting on the du! Apr 14 22:10:43 And 2GB for the mirror of the feeds themselves. Apr 14 22:11:06 mwester, we have room for that once we get the autobuilder setup. Apr 14 22:11:16 I can serve them up. Apr 14 22:12:18 Ok, without the rm_work, a full build of both LE and BE SlugOS takes ~68GB of disk, so with the other stuff already noted, we can easily fit inside 100GB of scratch. Apr 14 22:13:47 thats good because you have 86GB of scratch space. Apr 14 22:14:24 ka6sox-away: use LVM to be able to resize :) Apr 14 22:14:42 very useful Apr 14 22:14:58 I've already resized my partitions twice Apr 14 22:15:02 Jay7, we do have that on all bits...but I have 4 projects using the RAID0. Apr 14 22:15:23 eventually we will have more. Apr 14 22:15:37 use it for TMPDIRs only then Apr 14 22:15:45 right. Apr 14 22:15:52 tmpdirs is what I was thinking Apr 14 22:15:53 downloads/feeds/etc better to place to slow storage :) Apr 14 22:16:05 Yep. Apr 14 22:16:08 inputs and outputs will live on slower disk. Apr 14 22:16:31 * mwester has his downloads on NFS from a slow-but-gigantic RAID-5 file server. Apr 14 22:16:34 I have 64Gb for tmpdir here Apr 14 22:17:01 32Gb should be enough for simple builds Apr 14 22:17:16 but not for console-image+x11-image+opie-image :) Apr 14 22:17:17 so oe-core should fit in easily I suspect. Apr 14 22:17:22 I have 450GB for tmpdir on my big machine. :D But that's only because 500GB HDDs were the cheapest I could find after I filled the 160GB drive. Apr 14 22:17:26 + multiple machines :) Apr 14 22:18:01 for now scratch builds. Apr 14 22:49:41 * Jay7 -> sleep Apr 14 22:51:48 nn Jay7 Apr 14 22:59:52 03Stanislav Brabec  07master * r6e2627ed49 10openembedded.git/recipes/zaurusd/ (files/new-make.patch zaurusd_svn.bb): Apr 14 22:59:52 zaurusd: Convert Makefile.am spaces to tabs to be compatible with the new GNU make. Apr 14 22:59:52 Signed-off-by: Stanislav Brabec Apr 14 23:00:00 helloooo Apr 14 23:00:04 are there anyone? Apr 14 23:00:38 nobody here? Apr 14 23:03:59 I suspect it's more along the lines that nobody cares to answer that particular question. :p Apr 14 23:04:07 Perhaps if you asked a technical question? Apr 14 23:04:37 (but it's bed-time in EU, so many of those on the channel won't be able to answer till morning.) Apr 14 23:05:22 yes I know... and I'm Italian so I'm the first who want to sleep :) Apr 14 23:05:47 but i have a problem and i have to fig it out as soon as possible Apr 14 23:06:16 do you know how can I set an external arm compiler? Apr 14 23:06:52 it tell me:::: arm-angstrom-linux-gnueabi-gcc: No such file or directory Apr 14 23:07:01 so? Apr 14 23:08:48 Did it work before, or are you setting up to run an OE build for the first time? Apr 14 23:14:36 i worked on in since two weeks ago, then i had to format ubuntu so i did a backup of my oe folder and, replacing it i don't jknow why but there were not the /tmp/cross folder Apr 14 23:16:02 delete the tmp folder, and rebuild. Apr 14 23:17:03 (there's really no other solution when the tmpdir contents are damaged) Apr 14 23:18:24 maybe yes.... because i have a backup of the cross folder... but, trying to replace it, i have another error: wait a moment Apr 14 23:19:21 home/gilby/oe/tmp/cross/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/bin/ld: cannot find -lgcc_s Apr 14 23:21:00 You fight a losing and pointless battle, I am afraid. There is little chance to "patch together" the correct contents of the tmpdir; it is too complicated and interdependent to ensure that you have it right. Apr 14 23:21:50 just remove the tmpdir, or rename it, and build again -- much less trouble. Apr 14 23:23:16 ok ... i guess you are right... so thank you so much :) Apr 14 23:31:44 gilby: with oe-core it has whats called shared-state to repopulate tmpdir Apr 14 23:31:58 what with classic oe it does not Apr 14 23:32:15 you might try copying tricks but they sometimes dont work Apr 14 23:32:22 due to permissions changes etc. Apr 14 23:32:33 so its better to rebuild from scratch **** ENDING LOGGING AT Fri Apr 15 02:59:57 2011