**** BEGIN LOGGING AT Wed Apr 13 02:59:57 2011 Apr 13 03:04:59 Openfree`, tr is often used for this kind of thing Apr 13 03:06:00 grg, tr is a external shell program, does make have any built-in function? Apr 13 03:06:19 ok, at least it works Apr 13 03:06:20 dunno. Check the GNU make manual i suppose Apr 13 03:06:39 Checked, haven't found yet Apr 13 03:14:43 No gmake has no built-in to do that; you'll have to use the $(shell) macro with the tr utility. Apr 13 03:15:15 But in general it's poor form to convert case; why not write the rules in such a way that the case is correct to begin with? Apr 13 06:30:07 is there any way to force bash when there is /bin/sh -> dash link and user doesn't have root access? sanity check is failing and root wants dash because some other scripts (they say) Apr 13 06:32:10 good morning Apr 13 06:32:26 JaMa|Wrk: set SHELL env ? Apr 13 06:36:23 setting SHELL wont work, because a script with #!/bin/sh will execute /bin/sh Apr 13 06:37:00 the only way is to fix scripts that say #!/bin/sh but use bash features Apr 13 06:37:08 or change the symlink Apr 13 06:38:29 cannot change symlink without root :/ Apr 13 06:38:57 mckoan: I'm running builds under bash, but as grg said.. problem is with scripts having #!/bin/sh Apr 13 06:39:12 and sanity check for same reason :) Apr 13 06:39:47 grg: or change shebang to #!/bin/bash :) Apr 13 06:40:02 asssuming you can identify problematic scripts, yeah Apr 13 06:40:14 i suppose the only other option is to run a VM Apr 13 06:40:27 but you probably need root to set that up Apr 13 06:41:08 I have chroot for OE builds on other machines.. but still need root to chroot on this one :/ Apr 13 06:46:01 local root exploit? :P Apr 13 06:46:13 I'm sure its an unpatched system Apr 13 06:46:52 hehe, it's donated VM and more importantly BW, so I don't want to make them angry Apr 13 06:47:30 you could ask the admin nicely Apr 13 06:48:24 I asked for bash and had it for few days.. but then they reverted back to dash (having some compatibility issues with some other script) Apr 13 06:49:20 I'll try to find someone with pass knowledge as chroot is allowed in sudoers with passwd.. Apr 13 06:49:25 maybe ask for a sudo access to a speciifc chroot Apr 13 06:49:37 :) great minds think alike Apr 13 06:49:42 (and so do ours) Apr 13 06:49:43 :) Apr 13 06:50:32 * grg watches the clock Apr 13 06:52:27 btw this is imho also issue with dash http://paste.pocoo.org/show/370800/ Apr 13 07:51:13 Hi all Apr 13 07:52:16 ciao Apr 13 07:52:28 g'morning Apr 13 07:52:44 Just a question : which is the best method to totally clean a package with bitbake? I mean removing also downloaded sources, stamps, ipk... Apr 13 07:52:53 ciao ant! Apr 13 07:53:12 bitbake -c clean package Apr 13 07:53:18 but sources will stay Apr 13 07:53:23 no...that doesn't work very well Apr 13 07:53:39 because when I rebuild the package it seems to skip some stages Apr 13 07:53:58 mrAlmond: with sstate? Apr 13 07:54:23 I don't know what sstate is Apr 13 07:54:35 you're using poky or oe-core right? Apr 13 07:54:36 is it a bitbake command? Apr 13 07:54:39 poky Apr 13 07:54:44 yes Apr 13 07:55:37 then removing package files from sstate-cache and tmp/sstate-control should help Apr 13 07:56:27 ok I'm trying right now Apr 13 07:57:21 BTW I'm getting problems with xextproto in poky using the latest meta-openembedded layer Apr 13 07:57:31 because it doesn't seem to install xextproto.pc Apr 13 07:57:41 it just installs an empty file Apr 13 08:00:53 JaMa : that fixed the clean problem! Tnx!! Apr 13 08:01:02 Is that a bug? Apr 13 08:03:09 don't know iirc older pstage worked the same Apr 13 08:07:54 No, staging package was removed. I'd call that a mismatch between oe-classic and oe-core/yocto Apr 13 08:08:18 maybe a bug, even Apr 13 08:09:40 * ant_work still has to make his hand dirty with the new layer structure Apr 13 08:20:19 I'm creating a recipe for an own app which compiles a tool for the host, to configure. This fails because this part is built as arm also. I tried adding CMAKE_FORCE_C_COMPILER(x86_64-pc-linux-gnu-gcc GNU) Apr 13 08:20:19 CMAKE_FORCE_CXX_COMPILER(x86_64-pc-linux-gnu-g++ GNU) in own CMake file for this part which does the job, that the right compiler is selected, but it fails because -march=armv5te -mtune=arm926ej-s and -mthumb is added - is there a way to remove this in CMake file for this part? Apr 13 08:20:28 or what would be the best way? Apr 13 08:22:26 inherit cmake dont works? Apr 13 08:26:01 this works, cmake runs well, but in cmake i want build a tool for the host, which is compiled for arm - it has an own cmake file where i tried forcing the host compiler which works, but it gets flags for arm (march, mtune, mthumb, ...) I'm looking for a way to disable in *this* cmake file Apr 13 08:34:30 devzero_ look at llvm2.9 Apr 13 08:34:42 they are doing the same thing Apr 13 08:35:15 i'll check, thx Apr 13 08:37:41 morning all Apr 13 08:39:22 hi bluelightning Apr 13 09:13:48 woglinde, bluelightning, maybe you remember the steps who lead us to the current modules management situation Apr 13 09:13:59 I see still traces of modutils Apr 13 09:15:11 oe-core took both modutils-initscript and module-init-tools from OE Apr 13 09:15:16 no sorry Apr 13 09:15:41 what's unclear to me are th efile in /etc about autoloading Apr 13 09:16:45 now I don't have rootfs offhand but I'd bet there is /etc/modutils.d Apr 13 09:16:47 ant_work: been too long since I looked at that stuff I'm afraid... we're talking Familiar days... Apr 13 09:17:42 maybe sync with debian-style like for the rest? Apr 13 09:26:59 hi kgilmer Apr 13 09:30:01 hi woglinde :) Apr 13 10:31:08 hi Apr 13 10:31:57 hi obi Apr 13 10:32:15 03Jose Luis Perez Diez  07master * r3a31a6f381 10openembedded.git/recipes/connman/ (connman_0.72.bb files/shr/connman): Apr 13 10:32:15 connman: update shr config, don't enable DNS Proxy on connmand start Apr 13 10:32:15 * keeps current /etc/resolv.conf for usb0 Apr 13 10:32:15 Signed-off-by: Martin Jansa Apr 13 10:33:15 hm wow so many intel emplyoees working on yocto Apr 13 10:33:20 and oe-core Apr 13 10:50:24 hi gnutoo Apr 13 10:56:16 hi woglinde Apr 13 10:56:28 woglinde, you have a smartbook, right? Apr 13 10:56:31 GNUtoo could you try wesneoth? Apr 13 10:56:36 where? Apr 13 10:56:42 GNUtoo with latest oe-dev Apr 13 10:56:45 building Apr 13 10:56:53 ok, for me it built not so long ago Apr 13 10:56:59 since I have it on most of my devices Apr 13 10:57:02 I'll try at once Apr 13 10:57:03 GNUtoo I have an tegra2 toshiba ac100 yes Apr 13 10:57:08 I was busy with emacs Apr 13 10:57:32 is it 100% silent? Apr 13 10:57:37 how's the ubuntu support? Apr 13 10:58:01 woglinde, what distro for wesnoth? angstrom2010? Apr 13 10:58:09 yes Apr 13 11:13:11 ok I've rebased my changes, will now clean wesnoth-wvga and build it Apr 13 11:21:06 for the ac100, is it 100% silent, does it have a fan, what about the bootloader(is it floss) Apr 13 11:21:22 I bet there are no floss bootloader Apr 13 11:21:24 gnutoo its 100% slient Apr 13 11:21:29 the bootloader is not floss Apr 13 11:21:34 u-boot is working partly Apr 13 11:21:39 .37 is working Apr 13 11:21:54 main problems now are sound, shitty wifi and suspend Apr 13 11:23:23 ok Apr 13 11:23:36 I tough sound was solved Apr 13 11:23:38 go you bloody gps Apr 13 11:23:54 hm its solved with .32 now Apr 13 11:24:04 ok Apr 13 11:24:16 no buffer underruns or similar? Apr 13 11:25:00 I didnt test it yet Apr 13 11:25:29 ok Apr 13 11:26:05 the smartbook looks nice(dual screen possibility), but I wonder if it's solid enough now Apr 13 11:26:24 s/smartbook/smartbook from always innovating Apr 13 11:26:48 gnutoo ac100 is the cheapest Apr 13 11:26:53 you get for under 200 eruos Apr 13 11:26:54 now Apr 13 11:27:00 ok nice Apr 13 11:27:20 it can be bought in regular shops(where?) Apr 13 11:27:28 http://www.cyberport.de/notebook/restposten/netbooks/1E05-115/toshiba-ac100-10v-tegra-250-android-umts.html Apr 13 11:27:47 computer shops? carrier shops? Apr 13 11:28:07 look at your pricemachine in .it Apr 13 11:28:47 ok Apr 13 12:01:54 woglinde, where does wesnoth fails? Apr 13 12:02:05 NOTE: package wesnoth-wvga-1.8.4-r1.1: task do_install: Started Apr 13 12:06:42 GNUtoo hm there was one post on the mailinglist where boost is failing or so Apr 13 12:08:23 ah? Apr 13 12:08:25 let me look Apr 13 12:23:44 I've found a problem with mesa-xlib compilation in meta-openembedded Apr 13 12:24:09 patches are not found because are under mesa-7.10.2 instead of mesa-xlib-7.10.2 Apr 13 12:24:30 mrAlmond hm write to the ml Apr 13 12:24:47 which one? oe or poky? Apr 13 12:25:01 are you using oe-core? Apr 13 12:25:05 than oe-core Apr 13 12:25:13 I'm using poky + meta-openembedded Apr 13 12:25:21 poky Apr 13 12:25:25 but the problem is in meta-openembedded Apr 13 12:25:34 its poky Apr 13 12:25:40 ok Apr 13 12:25:50 but why it is hosted in oe git? Apr 13 12:26:00 dont ask me Apr 13 12:26:14 ok;-) Apr 13 12:26:17 you should use either oe-core with overlay or oe-dev now Apr 13 12:26:35 or 2011.3 maintance Apr 13 12:26:40 depending on your needs Apr 13 12:27:13 I must admit that I'm trying to understand the differences between poky and oe and all those layers Apr 13 12:27:26 hm okay Apr 13 12:27:33 oe was there first Apr 13 12:27:42 but it wasnt perfect for some companies Apr 13 12:28:06 so o-hand now intel made poky to clean up and using fewer recipes Apr 13 12:28:36 ok Apr 13 12:28:36 now there is the yocto project which goal is to boost linux embedded stuff a bit more Apr 13 12:28:49 base will be oe-core Apr 13 12:29:02 which is like poky Apr 13 12:29:31 is it identical? Apr 13 12:29:33 and you add overlays to it like various distributions angstroem/shr .. Apr 13 12:29:35 no Apr 13 12:29:43 consider it more a merge Apr 13 12:30:09 and what do you suggest to use...I need to build a custom rootfs for an arm based device Apr 13 12:30:12 mrAlmond: I'll fix mesa-xlib.. Apr 13 12:30:24 mrAlmond: look at mesa-dri for fix (FILESPATH..) Apr 13 12:30:24 thanks Jama! Apr 13 12:31:08 btw...I started with oe...then I passed to poky because it was kind of simpler than oe Apr 13 12:31:13 mrAlmond you can still using poky Apr 13 12:31:22 but you should have an eye on yocto Apr 13 12:31:26 and oe-core Apr 13 12:31:57 but in the yocto project the build system is still poky Apr 13 12:32:17 hms Apr 13 12:32:33 poky.git is now oe-core+bitbake in one repo Apr 13 12:32:58 maybe very small difference Apr 13 12:33:20 ok Apr 13 12:33:25 http://www.yoctoproject.org/blogs/davest/2011/yocto-project-turns-1.0 Apr 13 12:33:26 RP is merging commits to both repos oe-core and poky.git at the same time Apr 13 12:33:41 yes I've just seen that is out that newer version Apr 13 12:34:25 so now I'm starting to understand... :-) Apr 13 12:34:30 fine Apr 13 12:35:01 and the meta-openembedded layer is not for yocto? Apr 13 12:35:32 I've started to use that one because I needed xorg-xserver that it wasn't available in poky laverne Apr 13 12:35:37 seems so Apr 13 12:35:45 it is for yocto Apr 13 12:35:45 good Apr 13 12:36:06 mrAlmond: and xorg-xserver is there too under different name afaik Apr 13 12:36:33 yes...I mean that I needed the xorg server...not kdrive Apr 13 12:37:09 mrAlmond: openembedded-core/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite_1.7.99.2.bb Apr 13 12:38:04 and is the fbdev driver available for that one? Apr 13 12:38:35 yes in meta-oe layer Apr 13 12:38:59 ok...that's the one I'm using with poky Apr 13 12:39:11 thank you guys Apr 13 12:39:25 bye till later Apr 13 12:39:31 bye Apr 13 12:39:35 but with meta-oe is better to use xserver-xorg directly instead xserver-xf86-lite Apr 13 12:39:43 yes Apr 13 12:39:51 that's what I'm doing :-) Apr 13 12:40:18 because in meta-oe is quite fresh 1.10.0.902 instead old 1.7.99.2 :) Apr 13 12:42:06 great Apr 13 12:44:26 So now I'm downloading from the yocto site the new poky 5.0 Apr 13 12:44:49 will it include also the updated meta-openembedded layer? Apr 13 12:44:57 no Apr 13 12:45:12 so I've to add it in my bblayers.conf Apr 13 12:45:18 yes Apr 13 12:45:39 but why is it not included in this new release? Apr 13 12:46:08 because meta-oe is "extra" stuff applied on top of what is released as poky (still oe-core+bitbake) Apr 13 12:47:11 oook Apr 13 12:47:14 understood Apr 13 13:42:00 btw I've a fix for smpeg Apr 13 14:03:28 JaMa : I'm having troubles with the imlib2 recipe in meta-efl Apr 13 14:03:46 the LIC_FILES_CHECKSUM is missing Apr 13 14:04:00 there is no .inc file for it Apr 13 14:05:25 mrAlmond: strange that I didn't got it before, but please add and send patch with it if you can Apr 13 14:05:38 mrAlmond: I'll add such patch to my next pull request Apr 13 14:05:46 I don't know how to fix it.. Apr 13 14:05:56 LICENSE is BSD Apr 13 14:06:41 mrAlmond: http://www.pokylinux.org/doc/poky-handbook.html#usingpoky-configuring-LIC_FILES_CHKSUM Apr 13 14:06:41 is that LIC_FILES_CHECKSUM used for what? Apr 13 14:06:47 tnx!! Apr 13 14:07:07 I admit I should get a RTFM :-D Apr 13 14:07:23 I can add it for you, but I'm in middle of long build and it's good for you to learn it sooner then later :) Apr 13 14:07:34 you are right Apr 13 14:07:50 NOTE: Running task 4393 of 6246 Apr 13 14:12:50 03Denis 'GNUtoo' Carikli  07org.openembedded.dev * rba5581f225 10openembedded.git/recipes/smpeg/smpeg_svn.bb: (log message trimmed) Apr 13 14:12:50 smpeg svn: fix compilation Apr 13 14:12:50 Without that fix we have: Apr 13 14:12:50 [...] -L/usr/lib [...] libsmpeg-0.4.so.0 -o .libs/libsmpeg-0.4.so.0.1.4 Apr 13 14:12:50 /usr/lib/libm.so: file not recognized: File format not recognized Apr 13 14:12:50 In config.log we had: Apr 13 14:12:50 SDL_CFLAGS='-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT' Apr 13 14:12:51 fix for smpeg comming Apr 13 14:12:54 here it is Apr 13 14:18:38 well I get the LIC_FILES_CHECKSUM row from emotion_svn.bb and I've placed in imlib2 recipe...and it worked...probably it has the same license Apr 13 14:21:07 probably.. most efl recipes share same COPYING file Apr 13 14:27:43 well now I'm getting problems with xextproto version...it seems the newer xorg-xserver needs xextproto 7.2.0 but unfortunately the build installed the 7.1.2 from the original poky Apr 13 14:27:54 7.2.0 is available in meta-openembedded Apr 13 14:28:06 but bitbake xextproto install the old one Apr 13 14:28:38 check PE Apr 13 14:29:10 PE is the "priority"? Apr 13 14:29:53 it has the same value for both the receipes Apr 13 14:29:55 1 Apr 13 14:29:58 hmm both seems to have 1 Apr 13 14:30:03 package epoch Apr 13 14:30:48 is this a sort of bug? Apr 13 14:31:01 must I increase the one I need? Apr 13 14:31:20 no.. it's some include file in poky Apr 13 14:31:42 openembedded-core/meta/conf/distro/include/preferred-xorg-versions.inc Apr 13 14:32:16 this ^ is locking old versions for you Apr 13 14:33:11 so I must change them to 7.2.0..all of them about xextproto Apr 13 14:33:19 I hope I don't need to rebuild everything Apr 13 14:33:46 well, we have to recognize there is still a bit of confusion wrt poky Apr 13 14:34:02 0_0 yes Apr 13 14:34:39 mrAlmond: that's why I've removed this file from oe a while ago.. to make latest versions always default Apr 13 14:34:50 ant_work, that was a big topic at the Yocto Bof session yesterday Apr 13 14:35:00 I bet ^_^ Apr 13 14:35:05 http://www.flickr.com/photos/32615155@N00/sets/72157626489821744/with/5615828817/ Apr 13 14:35:21 we are working on sorting it all out, but it will take time Apr 13 14:35:43 I think the intel part of yocto is really surprised at the depth of confusion Apr 13 14:35:51 but I believe they understand now Apr 13 14:36:16 it has been really interesting to se the interest level though Apr 13 14:36:23 still a whole crapload of stuff in oe-core which I dont beleivew should be there Apr 13 14:36:33 and the sheer number of people that know what OE is :) Apr 13 14:36:34 about layers, angstrom distro and shr have some custom Apr 13 14:36:40 what about minimal distro? Apr 13 14:36:50 and the amount of misunderstanding of OE :) Apr 13 14:37:29 Crofton: I'm still confused about poky too :-) Apr 13 14:37:37 I need to get ready to go over to the last day if elc Apr 13 14:37:51 sakoman, that really became apparent yesterday att he Bof Apr 13 14:37:55 at the Apr 13 14:37:58 * XorA|gone is just generally confused about life :-) Apr 13 14:38:07 * sakoman is too Apr 13 14:38:08 hmmm Apr 13 14:38:14 I saw the stagecoach thing Apr 13 14:38:16 here's are my tests: Apr 13 14:38:24 *emacs 23.2 compiles Apr 13 14:38:27 Crofton: the poky name should go -- it really adds no value Apr 13 14:38:28 I am going to really confused tomorrow morning Apr 13 14:38:32 yes Apr 13 14:38:33 *emacs-x11 23.2 fails with: Apr 13 14:38:37 I think everyone sees that now Apr 13 14:38:42 it jsut takes time Apr 13 14:38:44 qemu: uncaught target signal 11 (Segmentation fault) - core dumped Apr 13 14:38:45 Segmentation fault Apr 13 14:38:46 yup Apr 13 14:38:47 when running: Apr 13 14:38:59 LC_ALL=C qemu-arm -cpu cortex-a8 -s 1048576 -L /home/gnutoo/embedded/oe/oetmps/shr/work/armv7a-oe-linux-gnueabi/emacs-x11-23.2-r1.0/qemu-treedir temacs Apr 13 14:39:07 and after yesterday's flailing with people trying to explain it, I thinnk it will happen faster Apr 13 14:39:08 I tried that: Apr 13 14:39:13 Crofton: has the next meeting been finalized yet? Apr 13 14:39:14 on target Apr 13 14:39:20 it works Apr 13 14:39:22 so it's qemu Apr 13 14:39:31 JaMa : So do you think I must set those variables to 7.2.0 ? Apr 13 14:39:34 what to do? Apr 13 14:39:38 debug qemu? Apr 13 14:39:44 no Apr 13 14:40:03 I am getting really confused about things, it will take me a day to figure it everything out Apr 13 14:40:09 people are still confused by all this? guess we need better info available on the web Apr 13 14:40:16 :) Apr 13 14:40:43 ok guys, I need to get going Apr 13 14:40:56 I think I have finally figured out Yocto Apr 13 14:41:00 in my own way Apr 13 14:41:16 it gives us a place to direct new users so they do not interfere with developers :) Apr 13 14:41:26 the info on the yocto site really doesn't seem to make things less confusing. pages you'd think would explain what poky is relative to oe-core just .. don't Apr 13 14:41:27 heh Apr 13 14:41:38 kergoth, understood Apr 13 14:41:46 poky also has had several meanings Apr 13 14:41:56 and has a really cool mascot :) Apr 13 14:41:57 ok Apr 13 14:42:00 guys later Apr 13 14:42:00 still RP answered to my question "OE or Poky ?" with those words "I think my last email made it clear the proposal was we'd collaborate Apr 13 14:42:02 around an "openembedded-core", not Poky." Apr 13 14:42:12 he unserstands Apr 13 14:43:44 what should I do for qemu? Apr 13 14:47:30 sakoman: naming of the layers was my second question :) Apr 13 15:10:30 Hmm. Icedte6-native fails on 2011.03-maintenance with "icedtea-jdk-build-sizer-32-on-amd64.patch: No such file or directory" Apr 13 15:14:22 hej, is there already a document on how to get changes int oe-core? (are ppl pulling from master?) Apr 13 15:26:24 mkneissl: the commit which updated to 1.7.10 removed the patch Apr 13 15:28:06 which version are you building? Apr 13 15:42:55 mlip: yes Apr 13 15:43:12 mlip: you can start with angstrom if you like Apr 13 15:44:18 http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/setup-scripts/ Apr 13 15:44:50 mlip: for patches you can either send to openembedded-core ml or send pull request to same ml Apr 13 15:45:24 khem: ah ok, I was just wondering about util-macros is 1.11.0 in oe-core and 1.13.0 in org.oe.dev Apr 13 15:45:44 (and this is the reason libx11 is failing for me using oe-core/etc.) Apr 13 15:46:10 makes sense to me. Apr 13 15:46:36 mlip: cook up a patch Apr 13 15:46:40 send to ml Apr 13 15:46:43 I will stage it Apr 13 15:47:28 khem: hey. Do you remember why you moved udev from rc S04 to S03 ? Apr 13 15:47:46 have been away from oe due to some work related reasons, and this bblayers thing is still kinda new :) Apr 13 15:47:57 so I didn't even know about the -core ml Apr 13 15:48:07 mlip: yes its new and we all are learning it fast Apr 13 15:48:29 ant_work: udev needed to run earlier Apr 13 15:48:36 I dont remeber what as the dep Apr 13 15:49:19 the risk is sysfs is run after udev and not before... Apr 13 15:50:10 khem, one more thing, I have utils-macros-1.13.0 in a local layer, bitbake still prefers the 1.11.0 version; bitbake -s shows both versions for this package; what's missing? Apr 13 15:55:01 mlip: bitbake -e | grep PREFERRED_VERSION_util-macros= Apr 13 15:55:17 could also be DEFAULT_PREFERENCE in either recipe Apr 13 15:56:25 kergoth, PREFERRED_VERSION_util-macros="1.11.0" - that makes sense then Apr 13 15:58:08 mlip : I have the same problem with gst-plugins-base Apr 13 15:58:19 it is preferring an older version Apr 13 15:58:29 how can I choose the one I need? Apr 13 15:58:33 ... Apr 13 15:58:39 define the variable i just said like 2 minutes ago? Apr 13 15:58:51 oppss Apr 13 15:58:53 sorry Apr 13 15:58:56 kergoth, can I find out how the pref. version is set? actually I have a local layer with priority 10, so this should be prefered? (default pref is not set) Apr 13 15:58:56 I miss that line Apr 13 15:59:04 mlip: grep. Apr 13 15:59:26 must I set it in my machine conf ? Apr 13 15:59:36 bitbake doesn't give a shit where you set a variable, ever. Apr 13 15:59:40 what matters is whether its set Apr 13 16:00:00 ok Apr 13 16:00:25 so no, set it wherever you like. wherever is *appropriate*. local.conf is a good place when testing things, can always move it elsewhere when you know it works Apr 13 16:00:28 I just wanted to know where these kind of preferences are set Apr 13 16:00:54 ok tnx Apr 13 16:00:57 generally speaking, the distro defines things like recipe versions. distro controls overarching policies and selections of things Apr 13 16:01:07 machine only controls things speciifc to that device. Apr 13 16:01:14 kernel version, which kernel recipe to use, etc Apr 13 16:01:28 good Apr 13 16:01:57 any given distro *should* be able to work on any given device, within reason. they're largely orthogonal Apr 13 16:02:06 that's why we separated it like this Apr 13 16:04:17 at the moment I'm using the poky distro Apr 13 16:04:45 kergoth, thx, missed preferred-xorg-versions.inc Apr 13 16:04:49 mlip: np Apr 13 16:05:07 in its meta layer there is a gst-plugins-base version newer than the one in the meta-openembedded layer Apr 13 16:05:21 mlip: in the future, we intend to make it possible to be able to determine where vars were set, when looking at the metadata with bitbake -e Apr 13 16:05:33 mlip: but today we're missing tracking of filename/linenumber <-> variables Apr 13 16:08:42 mrAlmond: in addition to explicit preferences, layers have priorities, which alter how it decides what to build Apr 13 16:08:47 ant_work seems to have left, but in the 2011.03-maintenance branch, the Icedtea5-native_1.7.10.bb still refers to the removed patch. http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/icedtea/icedtea6-native_1.7.10.bb?h=2011.03-maintenance&id=249b97a7c95194e12f71138280a967fa0d0ea9ae Apr 13 16:09:44 kergoth: and where can I check these priorities? Apr 13 16:10:28 mrAlmond: the layer.conf files in each layer Apr 13 16:10:40 ok tnx! Apr 13 16:11:14 or to see at a glance, bitbake -e | grep BBFILE_.\*= Apr 13 16:11:25 great Apr 13 16:11:59 each layer gets added to BBFILE_COLLECTIONS, and each has a BBFILE_PATTERN_ which controls how it matches files to the layers they're in, and BBFILE_PRIORITY_ which controls how it handles a given recipe being available in multiple layers Apr 13 16:12:24 (this actually existed before the proper layers mechanism, hence the different naming) Apr 13 16:17:05 so an higher priority value means that that a package in that layer will be preferred to the same available in an another layer Apr 13 16:18:31 right Apr 13 16:18:52 the idea is that more specific layers can override more general ones, so e.g. a particular distro or machine's layer can override the core Apr 13 16:19:24 not unlike how overrides function in oe, our metadata is essentially layered as well, from more general (e.g. bitbake.conf) to more specific (e.g. arch, then machine) Apr 13 16:20:40 hi everybody Apr 13 16:21:06 I have run into a problem, is anyone using ubuntu 11.04 yet? Apr 13 16:22:03 I've had new ubuntu releases explode in my face way too many times to go anywhere near them for the first 6 months or so, personally Apr 13 16:22:11 because they moved a lot of the system libs around and now perl-native fails to link Apr 13 16:22:36 I've had mixed luck with new ubuntus, so I try them on not my main computer Apr 13 16:23:12 also the machine i tried it on needd the most bleeding edge kernel (or something close anyway) for it's enet and wifi Apr 13 16:23:49 but my question is, how hosed will i make OE by saying ASSUME_PROVIDED="perl-native" Apr 13 16:23:58 will is successfully use the system perl Apr 13 16:24:15 you can't crosscompile things like perl without having a matching version build arch version Apr 13 16:24:32 so everything but target perl should be okay, but you're essentially on your own with something that bleeding edge ;0 Apr 13 16:24:46 still, its good that someone is blazing a trail with it Apr 13 16:25:11 kergoth, regarding overrides: is it also possible to override single .inc files in conf/distro/include in another layer? Apr 13 16:25:13 if you would, jot down your experiences with it, i'm sure we'll want to get the kinks worked out, at the very least info on the wiki on how to get a build there would be useful Apr 13 16:25:27 mlip: yes, it finds those via BBPATH, and each layers is in BBPATH Apr 13 16:25:36 mlip: now, here's where there's a kink in the implementaiton, though Apr 13 16:25:42 cool stuff Apr 13 16:25:47 it didn't work for me though ;) Apr 13 16:26:03 mlip: the layer.conf is what adds the layer to BBPATH, but it chooses whether to append or prepend, and either way its influenced by the order of the layers in BBLAYERS in you bblayers.conf Apr 13 16:26:08 rather than being based on the bbfile priorities Apr 13 16:26:27 so we have a potential mismatch in preferences between recipe and configuration files Apr 13 16:26:57 it parses the layer.confs in the order that they're listed in in BBLAYERS Apr 13 16:27:01 bitbake -e | grep BBPATH= Apr 13 16:27:07 it'll use the first file it finds in BBPATH Apr 13 16:27:13 kergoth, I see, this may be the problem here Apr 13 16:27:13 so thats the definitive way to see what it'll be using Apr 13 16:27:31 thx, I will have a look at it Apr 13 16:27:32 most layer.confs append to bbpath, which means you'd want the higher priority layers listed first in BBLAYERS Apr 13 16:27:35 see if tha thelps Apr 13 16:27:51 and if you have any ideas on how we can implement this in bitbake to not suck, let me know ;) Apr 13 16:29:43 the easiest would probably be a resorting of the BBLAYERS depending on the layer priority in layer.conf; maybe I will have a look at it Apr 13 16:30:17 for now I am just happy that I can continue trying to build a gumstix layer ;) Apr 13 16:31:50 hmm, the problem is fundamentally that the perl build process ignores the compiler's internal include path, and ubuntu moved all the `core` libs into /lib/x86_64-linux-gnu Apr 13 16:32:02 and now perl can't find pthreads or libm Apr 13 16:32:15 mlip: of course, the problem is that the layer.conf is what controls the add to bbpath, it could prepend and totally hose us ;) Apr 13 16:32:34 mlip: we really need to adjust BBPATH directly to fix the layer ordering, i expect, but thats a bit more complecated Apr 13 16:32:58 this is why i disagreed with the RP's bblayers implementation to begin with, part of hte priority is in *user* control, and part is in *layer* control Apr 13 16:33:15 but i didn't have any better ideas ;) Apr 13 16:33:33 we'll have to reimplement some of this to add layer dependency support, maybe we can fix it then Apr 13 16:33:52 kergoth, a I think I get it now Apr 13 16:34:22 BBFILE stuff isn't an issue, because the order in BBFILES is irrelevent, its entirely controlled by the BBFILE_PRIORITY vars Apr 13 16:34:33 i think we need to just scrap some of these old vars and do something from scratch Apr 13 16:34:35 heh Apr 13 16:34:40 i personally think BBFILES sucks Apr 13 16:34:51 * Nedlinpopo seconds that Apr 13 16:34:59 it wasn't intended to stick around this long Apr 13 16:35:06 it too easily produces untraceable errors Apr 13 16:35:12 not sure what you mean by that Apr 13 16:35:47 it makes it really easy to hide what's going on, since it gets muted further down the pipeline Apr 13 16:37:02 which i guess isn't strictly a programmer problem, but non ethe less it's dificult for a user of the tree Apr 13 16:37:58 can you elaborate? are you thinking about the case where bbfiles doesn't match any files? the globs don't match anything? Apr 13 16:39:17 03Koen Kooi  07org.openembedded.dev * r5dd1cc0342 10openembedded.git/recipes/ncurses/ (ncurses/ncurses-5.7-20110108-patch.sh.bz2 ncurses_5.7.bb): Apr 13 16:39:17 ncurses 5.7: put patch in OE Apr 13 16:39:17 The patch disappeared and apache on the sourcemirrors doesn't allow downloading of '.sh' files. Apr 13 16:39:17 This is *exactly* why we keep patches in OE instead downloading them from unreliable websites Apr 13 16:39:17 Signed-off-by: Koen Kooi Apr 13 16:40:01 no, I spent a lot of time last night trying to figure out what recipe was actually getting used (or not used as was the case) Apr 13 16:40:56 because the error wasn't aobut the recipe not being found, but instead about some inheritance issue Apr 13 16:41:06 well, whether we use BBFILES or not, that'd still be an issue, because we'll always support having multiple instances of a recipe existing in multuiple layers, regardless of how its specified Apr 13 16:41:21 which may just be a simple UI tweak. Apr 13 16:41:26 iI see your point Apr 13 16:41:48 bitbake-layers will improve this, however. its intended to be a tool to tell you about your layers. today it will list bbappend files being used, and warn about certain issues with it. but another subcommand will likely be "show me what recieps are in what layers, with versions" Apr 13 16:42:17 sort of like a layer specific bitbake -s Apr 13 16:42:28 i bet that would help this, particularly if we make it obvious which is currently preferred Apr 13 16:42:42 asterisk it perhaps, and also list the layers in priority order Apr 13 16:43:18 can I request that the documentation for bitbake make it painfully clear that BBPATH is where bitbake will look for non-recipes, and BBFILE is where bitbake will look for recipes? Apr 13 16:43:39 yeah, if that's not the case, that's just a bug in the docs, that's a problem Apr 13 16:43:47 that piece of learning was a little hard fought Apr 13 16:44:12 agreed Apr 13 16:44:45 i happen to think, usability wise, collections.inc was superior to the current situation. you'd set COLLECTIONS = "/path/to/a /path/to/b /path/to/c", in priority order, and it set BBPATH to match, set BBFILE* to match, *and* set BBFILES to search those paths to find any recipes in them Apr 13 16:44:57 course, i wrote that .inc, so i'm biased Apr 13 16:45:15 oh, and the output of bitbake -e is broken if DISTRO is not found Apr 13 16:45:34 heh, more than just -e is broken if DISTRO isn't found, right now, due to parsing errors Apr 13 16:45:35 I never used it the old way Apr 13 16:45:47 we need to inject a really, really early check for unset/invalid DISTRO Apr 13 16:46:21 yeah, i think there's a chicken/egg problem there, but it would hav emade my life a whole lot happier last night Apr 13 16:47:13 the thing of it is, distro is used in OVERRIDES, and OVERRIDES are used at multiple points in the parsing process, so trying to inject a check *before* they're processed might be problem. we may have to change how the distro/overrides bits are done Apr 13 16:49:12 bugger Apr 13 16:49:26 seems like people are trying to make one thing act for 2 Apr 13 16:53:37 heh, it used to be distro and machine were optional, just ways to avoid having to set all the vars yourself, but there are way too many for that to be the case anymore Apr 13 16:55:43 well, i can understand MACHINE, since that controls something about the build process, more than what to build, but why aren't DISTROS, just recipes? Apr 13 16:59:15 DISTRO controls overarching policies Apr 13 16:59:39 whether prefix is /usr or /, whether we support ipv6, etc Apr 13 16:59:55 hmmm Apr 13 16:59:58 it's not a recipe by definition, it controls how recipes are built Apr 13 17:00:14 interesting Apr 13 17:00:25 bitbake -e | grep DISTRO_FEATURES= Apr 13 17:00:27 | install: cannot stat `.../work/armv7a-angstrom-linux-gnueabi/funnyboat-1.5-r0/image/usr/share/games/funnyboat/water.py': Permission denied Apr 13 17:00:28 with: Apr 13 17:00:43 install -m 0655 ${S}/*.py ${D}/usr/share/games/funnyboat/ Apr 13 17:01:03 the destination exists Apr 13 17:01:23 was it installed previously? did you run a make install or setup.py install or something that installed it there before? or perhaps the directory isn't writable? Apr 13 17:01:38 the game is a .zip Apr 13 17:01:43 with inside no setup.py Apr 13 17:01:45 just some files Apr 13 17:01:47 GNUtoo, maybe it existed before that was called? I think -m means if it's there do nohting Apr 13 17:01:48 to copy somewhere Apr 13 17:01:57 Nedlinpopo: -m sets teh file mode Apr 13 17:02:09 ah Apr 13 17:02:26 0655 == rw-r-r- Apr 13 17:02:27 maybe it's -p that does nothing if it's already there Apr 13 17:03:23 -p, --preserve-timestamps apply access/modification times of SOURCE files to corresponding destination files Apr 13 17:03:53 it was not installed previously Apr 13 17:03:58 well, aparently I don't remember how to invoke install Apr 13 17:04:09 how many arguments install accepts Apr 13 17:04:13 something like that: Apr 13 17:04:18 install -m 0655 ${S}/*.py ${D}/usr/share/games/funnyboat/ Apr 13 17:04:22 result in: Apr 13 17:04:38 that's valid syntax for install Apr 13 17:04:45 install [OPTION]... SOURCE... DIRECTORY Apr 13 17:04:49 install -m 0655 /home/gnutoo/embedded/oe/oetmps/angstrom2010/work/armv7a-angstrom-linux-gnueabi/funnyboat-1.5-r0/funnyboat/PixelPerfect.py /home/gnutoo/embedded/oe/oetmps/angstrom2010/work/armv7a-angstrom-linux-gnueabi/funnyboat-1.5-r0/funnyboat/cannonball.py /home/gnutoo/embedded/oe/oetmps/angstrom2010/work/armv7a-angstrom-linux-gnueabi/funnyboat-1.5-r0/funnyboat/cloud.py ... Apr 13 17:06:27 bugger. well you've all been exteraly helpful, but it looks like i can drive this USB stick across town faster than the internet, so I'll see you later Apr 13 17:07:10 never underestimate the bandwidth of a fedex truck full of harddrives Apr 13 17:09:59 I'll try fakeroot do_install Apr 13 17:16:03 ah now unpack fails Apr 13 17:16:11 df -h shows about 200GB of free space Apr 13 17:16:15 I'll look at dmesg Apr 13 17:40:45 I think I got it Apr 13 17:41:22 what? Apr 13 17:41:25 hi effem Apr 13 17:42:48 gregoire is making my head explode Apr 13 17:43:00 crofton why? Apr 13 17:43:05 hi woglinde, all Apr 13 17:43:16 too many os'es at once? Apr 13 17:43:21 explaining how the super jumbo image works Apr 13 17:43:25 yeah Apr 13 17:43:30 ;) Apr 13 17:43:31 one kernel, many root fs' Apr 13 17:43:38 yes Apr 13 17:43:52 one kernel that works for "angstrom", android, chromium and ubuntu Apr 13 17:44:03 yes yes Apr 13 17:44:06 linus will eat this up Apr 13 17:47:20 Crofton, can you give a link ? Apr 13 17:47:34 not yet Apr 13 17:47:42 maybe on always innovating website Apr 13 17:47:57 the video talk will be online eventually Apr 13 17:48:02 03Tom Rini  07master * r62ceace6df 10openembedded.git/recipes/xkeyboard-config/xkeyboard-config.inc: Apr 13 17:48:03 xkeyboard-config: Add glib-2.0-native to DEPENDS Apr 13 17:48:03 Needed for glib-gettextize Apr 13 17:48:03 Signed-off-by: Tom Rini Apr 13 17:48:03 eFfeM you can read the summary on the elc site Apr 13 17:48:08 ah this was on elc, understood Apr 13 17:48:16 yes Apr 13 17:48:32 I am live reporting :) Apr 13 17:55:28 nice! Apr 13 17:59:33 the many headed hydra Apr 13 18:00:01 hi ka6sox Apr 13 18:00:08 hiya woglinde Apr 13 18:00:18 ka6sox at elc too? Apr 13 18:00:24 its been the usual, take teh drink from the firehose Apr 13 18:00:25 yes Apr 13 18:00:41 but working on different stuff (well..OE related) Apr 13 19:43:04 Hi all Apr 13 19:45:48 just a question...I'm compiling an image with xorg-xserver using poky + meta-openembedded grom the git repository. Now I'm getting error in fetching "screenshot" from the enlightment SVN...but I don't want to have EFL in my image Apr 13 19:46:12 who is requiring EFL to compile? Apr 13 20:49:02 mrAlmond: check the dependencies Apr 13 20:49:33 mrAlmond: something like bitbake -g -u depexp your-image-name Apr 13 20:49:53 that is assuming depexp is in poky's bitbake Apr 13 20:50:22 what is depexp ? Apr 13 20:50:38 alternative user interface to bitbake (dependency explorer) Apr 13 20:50:48 it will give you a list of packages and their dependencies Apr 13 20:51:09 so I should see who is including efl things Apr 13 20:51:50 that is strange because I'm compiling poky-image-core Apr 13 20:52:00 that normally uses Xfbdev + matchbox Apr 13 20:52:18 it's probably due to meta-oe layer somehow Apr 13 20:52:59 I've just added the preferred xorg-xserver Apr 13 20:53:07 set to xorg instead of kdrive Apr 13 20:54:03 oe-core/poky and meta-oe integration are still new. Many (most) folks are still using monolithic oe (like me). As such, we can't relate to your specific problems well. Apr 13 20:55:18 everyone, stop using the word "poky" :) Apr 13 20:55:24 kergoth: any patch to test wrt portmap / install permissions? I would lik eto stay on master... Apr 13 20:55:36 Crofton: tell yocto to stop calling it poky first ;) Apr 13 20:55:56 ant__: it's fixed.. has been since last week. current bitbake master works fine with current oe Apr 13 20:56:18 foerster, I do Apr 13 20:56:20 constantly Apr 13 20:56:40 kergoth: I missed it, pulled now, thx Apr 13 20:56:44 np Apr 13 20:56:47 so we have to call it just yocto ? Apr 13 20:57:15 As a (relatively light) user of OE, I find the whole situation confusing at the moment. Apr 13 20:57:19 mrAlmond: yocto isn't poky. yocto isn't oe. yocto isn't oe-core. it's an umbrella project, not any of the individual things it might be using. Apr 13 20:57:34 * kergoth thinks people are thinking it's more complex than it is Apr 13 20:57:51 but when you dowload yocto it downloads poky :-) Apr 13 20:58:03 so probably it's better to rename it Apr 13 20:58:06 if A includes B, that doesn't mean B is A. Apr 13 20:58:18 because it's still confusing Apr 13 20:58:41 poky is just yocto's productization of oe-core, as far as i'm aware. nothing more to it than that Apr 13 20:58:51 but i'm not at the conference, at the meetings, so *shrug* Apr 13 20:59:24 foerster, you are not alone, we are working on reducing confusion Apr 13 20:59:32 kergoth: they don't state it as such - http://yoctoproject.org/projects/openembedded-core Apr 13 20:59:44 they say "we used to use poky, now we'll be using oe-core" Apr 13 20:59:44 kergoth, I tried to make that point and failed miserably during the Yocto bof :) Apr 13 21:00:01 foerster, all this will change over the next few weels Apr 13 21:00:40 foerster: which is true. they are essentially using oe-core, they're just still calling their version of oe-core poky, for some strange reason. Apr 13 21:00:59 kergoth: and their bitbake is different still - no process based server Apr 13 21:01:08 yeah, that's the one big piece remaining Apr 13 21:01:16 some of the yocto ide stuff really needs the xml/rpc interface Apr 13 21:01:24 and we haven't resurrected a less crappy one of those yet Apr 13 21:01:37 we should be able to drop one in fairly easy I think. Apr 13 21:01:46 * kergoth and RP had some ... heated discussion ... about this Apr 13 21:01:52 that's what i said :) Apr 13 21:01:59 of course, I haven't had time to breath let alone put my money where my mouth is ;) Apr 13 21:02:17 trying to wrap up year-long project and get it all tested/released. Apr 13 21:02:47 * Crofton and lots of others (lots of others) are driving the sort out the terminology Apr 13 21:03:13 mind you, if they had started out using the OE name, it is likely we would have been unhappy with that also :0 Apr 13 21:03:16 the one thing remaining to sort out is how you choose your bitbake *server*. i personally think the user shouldn't choose the server directly (not via a cmdline arg) anyway. i think we should let the UI instantiate the server, and create a UI which spawns an xml/rpc or similar on a socket and prints the connection info to stdout Apr 13 21:03:33 kergoth: do you know off hand - does the xmlrpc stuff just serialize python objects back to the caller? I haven't had a chance to look at all. Apr 13 21:03:35 then add an env var to instruct the UIs to connect to an existing server, later on, if we need that Apr 13 21:03:45 i'm not sure exactly Apr 13 21:03:58 l8r Apr 13 21:04:09 in the old xmlrpc case, they just register the normal call handlers as rpc interfaces Apr 13 21:04:16 so it seems like that's the case (or something close) Apr 13 21:04:22 I really don't know that xml/rpc is an ideal solution. RPC seems like a bit of a cop-out, for when you're too lazy to do a proper protocol. given we just pass events and commands back and forth, it seems like overkill Apr 13 21:04:29 unfortunately the "bitbake -g -u depexp poky-image-core" started but ended with error on my poky laverne Apr 13 21:04:30 * kergoth shrugs Apr 13 21:04:37 kergoth: bitbake -s at server side and bitbake -c at other :) Apr 13 21:04:46 mrAlmond: if you're using poky, not OE, you should be in #poky Apr 13 21:04:47 or just bitbake to use as before Apr 13 21:05:20 kergoth: also there are major security implications if we allow running/connecting to different machines Apr 13 21:05:23 Jay7: I don't think so. it doesn't make sense. first of all, -s .. what exactly? users don't give a shit which server they're using Apr 13 21:05:30 Jay7: second, -c spawns a ui, -s doesn't? Apr 13 21:05:41 -s doesn't Apr 13 21:06:48 I think a UI should *always* be spawned, just in this case the UI only displays the information and exits, personally. particularly given we're going to be offloading some of the commandline argument handling to the UIs in the future Apr 13 21:06:49 ok guys...I'm going to bed...see you tomorrow Apr 13 21:07:01 thank you for everything Apr 13 21:07:14 use case: I'm starting bitbake -s inside lxc container then using bitbake -c (or export BB_SERVER=) and control that process Apr 13 21:07:28 yes.. that's exactly the case i'm talking about. i'm just talking about how to implement it. Apr 13 21:07:38 we obviusly want to start headless servers and be able to connect to them with a ui Apr 13 21:08:20 I actually would rather see our existing server gain more capabilities, rather than creating new servers, personally Apr 13 21:08:26 I think it would be less confusing that way Apr 13 21:08:29 its bad enough we have to pick a UI Apr 13 21:08:33 without having to pick a server as well Apr 13 21:08:48 heh Apr 13 21:08:51 * kergoth shrugs Apr 13 21:08:59 Yes. I think we can patch in xmlrpc fairly easily since they're not doing anything special with it anyway Apr 13 21:09:02 another possibility would be to have a separate script for spawning the server without a UI Apr 13 21:09:04 * kergoth nods Apr 13 21:11:28 if all we're doing is sending python objects back and forth, it should be trivial to drop in just about any transport mechanism, as long as we know how to serialize in an appropriate way. whether its pickle, xml, or protobuf or something.. Apr 13 21:11:43 though, thats more about data encoding than the actual transport mechanism Apr 13 21:11:52 its just that most other languages don't grok python pickle ;) Apr 13 21:13:23 yea. I'm looking now. It looks like they just register registerEventHandler, unregisterEventHandler, runCommand, terminateServer, ping as rpc methods Apr 13 21:14:59 and runCommand is essentially return cooker.command.runCommand Apr 13 21:15:12 so it looks like the xmlrpc transport is encoding the python object however it needs Apr 13 21:15:27 of course I could be completely wrong, but that's what it looks like at a quick glance ;) Apr 13 21:16:06 That's okay i guess.. but I think things improved when we moved to separating the UI and Server and using nice communications channels rather than function calls and not knowing what context you're in.. seems like xmlrpc is a step more toward the old way Apr 13 21:16:11 heh Apr 13 21:17:06 you may use stateful proto instead of stateless Apr 13 21:18:07 course, not having to worry about making sense of a serialized python object from another language directly is certainly less hassle, i can see why people use it, just for the convenience of it Apr 13 21:18:16 right. Apr 13 21:18:18 it's similar. Apr 13 21:18:26 we still essentially call runCommand from our UIs now. Apr 13 21:18:39 we just don't have to worry about decoding the response b/c we're talking python<->python Apr 13 21:19:22 true, i forgot we're still hiding that detail from them Apr 13 21:19:24 * kergoth nods Apr 13 21:20:13 i forget, I think we give the UI a "server communicator" or something like that Apr 13 21:20:35 it's only been a few months, but seems like years since we put that in Apr 13 21:20:57 yeah, though we had to change the UIs to interact with the queue for the events anyway, so it wasn't entirely transparent. just the command bits that we hid Apr 13 21:20:58 heh, yep Apr 13 21:21:34 ah, just looked. They don't call runcommand directly Apr 13 21:21:37 they send via the queue Apr 13 21:21:50 the server grabs off the queue, and calls the internal "runcommand" Apr 13 21:24:35 Our new UIs get a "ServerCommunicator" that writes into the command queue of the server. This effectively still ends up calling runCommand. So, we should be able to plum in xmlrpc somehow. Apr 13 21:24:50 I don't think we've deviated all that far Apr 13 21:58:34 what does the INHERIT variable do? Apr 13 22:15:50 Picks up the definitions of various variables and methods from the named file (and pays the government 50%) Apr 13 22:23:53 the file named in INHERIT? Apr 13 22:24:18 so INHERIT += "rm_work" reads some file named rm_work.bb? Apr 13 22:25:02 ah, a bbclass file Apr 13 23:15:43 is there any way to change which terminal is spawned by devshell Apr 13 23:16:02 gnome-terminal doesn't work for my ssh session Apr 13 23:16:17 due to some silly GCONF issues Apr 13 23:16:49 (or possibly a striping of some environment variables) Apr 13 23:23:02 Nedlinpopo: set TERMCMD Apr 13 23:23:07 in local.conf Apr 13 23:23:09 sweet Apr 13 23:23:37 can i set it to /bin/bash Apr 13 23:54:05 No Apr 13 23:54:33 you can set TERMCMD/TERMCMDRUN to any of XTERM_TERMCMD/TERMCMDRUN, GNOME_, KONSOLE_ or SCREEN_ Apr 13 23:55:05 Or you can define your own that spawns off something else, but you can't just do /bin/bash Apr 13 23:55:11 see bitbake.conf for how they're defined Apr 14 00:11:28 hmm, did i ever email my devshell revamp to the list? Apr 14 00:11:32 * kergoth checks gmail **** ENDING LOGGING AT Thu Apr 14 02:59:58 2011