**** BEGIN LOGGING AT Tue Jun 14 02:59:57 2011 Jun 14 05:09:05 has anyone attempted to build the ar drone kernel using oe? Jun 14 06:36:43 03Andrea Adami  07org.openembedded.dev * r22b971e958 10openembedded.git/recipes/kexec-tools/kexec-tools.inc: (log message trimmed) Jun 14 06:36:43 kexec-tools: don't depend on virtual/kernel Jun 14 06:36:43 * Imported from oe-core (ba6da75657d0bf9ed48f0d6c4132f12993648e7a) Jun 14 06:36:43 * There doesn't appear to be any terribly good reason for kexec-tools to Jun 14 06:36:43 * depend on the kernel. (I verified that kexec-tools is buildable in a Jun 14 06:36:44 * clean TMPDIR without having previously built virtual/kernel.) Jun 14 06:36:45 * Having this dependency in place is a nuisance because it makes it Jun 14 07:26:31 the console-image seems to use DES encryption for passwords by default giving an effective maximum password length of 8 characters, I want to change this to use md5 (i.e. chpasswd -m , mkpasswd -m md5) but cannot find any config file for this, does it have to be done at build time? Jun 14 07:57:36 pb_: today's consult would be about debian naming: should I just inherit+="debian" to get klibc -> libklibc? And apart the lib, what happens to the binaries in 'utils'? Jun 14 08:33:09 hii Jun 14 08:47:33 interesting commits in oe-core about INHIBIT_DEFAULT_DEPS = "1" for many recipes Jun 14 08:48:51 oe-classic starts to have too much drift to be put in sync with oe-core. Someone said 'pointless' Jun 14 08:49:03 I'm a bit confused about bb recipe variable namespacing, can anyone help me sort out my dimwittedness? Jun 14 08:51:56 have you read the (a bit outdated) documentation? Jun 14 08:52:06 in that case, just fire your q Jun 14 08:53:48 I've had a look in the bb and oe documentation, probably missed the answer I need :) Jun 14 08:55:00 So I have a recipe which would like to use KERNEL_VERSION as set in kernel.bbclass. What would I need to do to make sure that this recipe can access it? Jun 14 08:56:42 is just easy: Jun 14 08:57:12 Or to widen the question (in case there's a better way to solve this). I'm compiling an old kernel without falloc (vendor supplied kernel), I'd like to compile util-linux with --disable-falloc if kernel version < 2.6.25. Is there already a way to do that, before I invent my own? Jun 14 08:57:27 base_version_less_or_equal Jun 14 08:58:52 but I have a bad news...this fails with some fancy kernel version strings Jun 14 08:59:37 we had similar issue and wrote a workaround: see linux/linux-kexecboot.inc Jun 14 08:59:38 That saves me reinventing the version comparison, but I still need access to KERNEL_VERSION from util-linux*.bb Jun 14 09:01:44 In linux-kexecboot.inc you use PV, which won't work for util-linux :( Jun 14 09:02:29 I know I could call get_kernelversion from linux-kernel-base.bbclass, but it seems wasteful to re-parse the header. Jun 14 09:06:11 let me see the recipe Jun 14 09:06:54 Which one? Jun 14 09:07:46 I'm looking at root/recipes/util-linux/util-linux.inc Jun 14 09:08:12 That's the one. Jun 14 09:08:17 I see kernel is not listed in depends so you could actually build withouth it :/ Jun 14 09:08:47 no way to peek in STAGING_KERNEL_DIR Jun 14 09:09:00 I wonder if it's strictly a libc dependency. Jun 14 09:09:23 in oe-dev util-linux DEPENDS = "zlib ncurses" Jun 14 09:09:41 i.e.: util-linux needs falloc, provided by libc, dependent on kernel support. Jun 14 09:10:20 ok, those are default deps Jun 14 09:10:49 (libc and toolchain) Jun 14 09:11:51 Is libc configured for certain features depending on kernel support? Perhaps I could query the libc package instead of the kernel ver. Jun 14 09:16:21 *libc (apart klibc) do not compile against kernel headers Jun 14 09:16:53 but use linux-libc-headers instead Jun 14 09:18:36 Let me dig a bit more and get my facts straight on what fallocate in util-linux is really looking for, biab. Jun 14 09:19:11 ant_work, ping? Jun 14 09:19:21 hello Jun 14 09:19:34 hiya, if I find email addy's can you add to ML? Jun 14 09:19:43 I fixed the wiki already. Jun 14 09:20:03 I have no supercow powers Jun 14 09:20:30 okay, I'll ask pb_ then :D Jun 14 09:20:33 I would have collected a list to send to XorA or Crofton Jun 14 09:21:20 OK, fallocate.c in util-linux includes linux/falloc.h. So should it really depend on the kernel? Or does oe provide the kernel headers from a different package? Jun 14 09:21:52 ya, both would just forward it on to somebody else.... Jun 14 09:22:07 :] Jun 14 09:22:10 okay I fixed wiki though (although its not really alphabetical... Jun 14 09:22:12 ) Jun 14 09:22:36 I don't have cow_powers for ML Jun 14 09:25:11 hi all Jun 14 09:26:07 hii i'm trying to compile krb5 Jun 14 09:26:24 morning bluelightning Jun 14 09:26:30 i am getting some error in compiling Jun 14 09:26:48 configure: current value: -L/home/soulfood/build30may/build/tmp/staging/i586-linux/usr/lib -Wl,-rpath-link,/home/soulfood/build30may/build/tmp/staging/i586-linux/usr/lib -Wl,-O1 -lpthread | configure: error: changes in the environment can compromise the build | configure: error: run `make distclean' and/or `rm ../../.././config.cache' and start over | configure: error: /bin/sh '/home/soulfood/build30may/build/tmp/work/i586-linux/k Jun 14 09:27:16 anyone have idea Jun 14 09:27:22 any idea>> Jun 14 09:27:23 >> Jun 14 09:28:57 ka6sox-away: ping Jun 14 09:29:07 XorA, pong Jun 14 09:29:37 drainbamage: Can you paste the full configure log to pastebin? Jun 14 09:29:50 k Jun 14 09:31:13 http://pastebin.com/Rv53vLDw Jun 14 09:34:36 Have you tried doing what it says? Open a devshell for the app and run 'make distclean' Jun 14 09:35:13 LDFLAGS value has only whitespace diffs I think. Jun 14 09:36:09 ant_work: fallocate.c in util-linux includes linux/falloc.h. Does that mean it *should* depend on the kernel pkg? Or does oe provide the kernel headers from a different pkg? Jun 14 09:39:40 i've tried a clean make Jun 14 09:39:46 but the same error Jun 14 09:39:52 i'm getting again Jun 14 09:39:55 celston: sorry, phone call... Jun 14 09:40:01 brb Jun 14 09:40:04 ant_work, np :) Jun 14 09:40:19 drainbamage: define 'clean make' Jun 14 09:41:23 k Jun 14 09:41:25 let me try Jun 14 09:41:56 bitbake -c clean krb5 ? Jun 14 09:42:20 yeah i've tried this before Jun 14 09:42:40 celston: see kernel.bbclass Jun 14 09:43:11 are u able to compile krb5 ?? Jun 14 09:43:33 drainbamage: I'm doing board bring-up on a new platform, so no :) Jun 14 09:43:46 ohk Jun 14 09:45:02 ant_work: yep. Been looking in there all morning. Jun 14 09:45:23 kernel headers are staged per machine when building a kernel Jun 14 09:47:04 util-linux includes linux/falloc.h, so it should depend on the kernel recipe then? Jun 14 09:50:07 no, it should be getting the sanitized linux/falloc.h from linux-libc-headers Jun 14 09:50:27 well, I see some patches around Jun 14 09:50:29 Patchworkβ [oe,v4] linux-libc-headers_2.6.24: Add falloc.h to kernel exported headers Jun 14 09:50:36 the only things that should be compiling against headers from the kernel itself are kernel modules. Jun 14 09:50:48 'morning pb_ Jun 14 09:51:25 hi ant Jun 14 09:51:29 can anyone help me Jun 14 09:51:41 depends what help you need. Jun 14 09:51:48 haha Jun 14 09:51:49 are you drowning? on fire? Jun 14 09:51:56 lol Jun 14 09:52:14 plz help me krb5 compilation Jun 14 09:52:22 pb_: about the debian renaming..I'll try that. Hacking with FILES_ was leading me to bad issues with RDEPENDS Jun 14 09:52:24 what goes wrong for you? Jun 14 09:52:37 http://pastebin.com/Rv53vLDw Jun 14 09:53:22 oh, that's weird Jun 14 09:53:33 crazy krb5 seems to be doing some kind of recursive configure thing Jun 14 09:53:47 hmm.. Jun 14 09:53:52 I suspect that if you do a sed 's/ / /' kind of thing on LDFLAGS then that will probably sort it out Jun 14 10:05:01 morning pb_, sorry, been afk. Catching up now. Jun 14 10:06:59 pb_: in my case, there *is* no falloc.h, kernel is 2.6.18 (mmmm, vintage vendor kernel). So it's a question of how to pass --disable-fallocate to util-linux configure in this case. Jun 14 10:08:44 what linux-libc-headers are you using? Jun 14 10:09:18 and, well, you'd rather hope that util-linux would be able to figure out for itself that falloc.h was missing. This is meant to be one of autoconf's core competencies. Jun 14 10:09:44 in that regard I could find this: http://comments.gmane.org/gmane.linux.utilities.util-linux-ng/3511 Jun 14 10:09:51 Yes, that's my feeling on the matter too :) Jun 14 10:10:31 +1 fixed upstream :) Jun 14 10:18:47 anyone have idea regardin libldapsdk?? Jun 14 10:19:05 this lib comes with which package Jun 14 10:19:38 openldap maybe? Jun 14 10:19:59 k Jun 14 10:20:03 i'll try Jun 14 10:30:56 and libgssapi.so Jun 14 10:48:29 What controls which binaries busybox supplies? I'd like to replace the shell with a full featured bash (and a bunch of the other CLI utilities as well) Jun 14 11:06:11 anybody seen msgs like this before and know what it means? http://pastebin.com/UqZZFuVC Jun 14 11:06:17 hello Jun 14 11:06:50 I used the same tree to build for zaurus which works fine - built for tx25 and get those after kernel loads Jun 14 11:06:50 I'm trying to intall bitbake on slackware using 'pip install bitbake' Jun 14 11:07:02 and it doesn't work for some strange reason .. Jun 14 11:08:05 errordeveloper: which version of bitbake do they provide in slackware? Jun 14 11:08:54 ajb_oe: I think you'd just need to get the packages that provide the binaries you want installed Jun 14 11:09:21 well .. there is not slackware package Jun 14 11:09:26 ajb_oe: the alternatives system should handle things like bash where busybox otherwise provides a cut-down version of the same package Jun 14 11:09:34 hence i'm trying to use pip Jun 14 11:09:36 ajb_oe: erm, s/package/binary Jun 14 11:10:07 errordeveloper: hmm, ok, don't know anything about pip I'm afraid Jun 14 11:11:01 errordeveloper: if you're lucky you might find someone else who uses it here, but frankly I would suggest grabbing it from git or a release tarball and just extracting it next to your OE tree as most people do Jun 14 11:14:56 perhaps getting bitbake from the git repo is the best option really :) Jun 14 11:22:50 bluelightning: thanks... Jun 14 11:24:26 only libldap comes up with openldap package Jun 14 11:24:32 no ldapsdk Jun 14 11:24:40 libldapsdk Jun 14 11:41:41 pb_ ant_work: I have a 'style' question. I've added a recipe for a later version of util-linux (which includes the patch ant_work pointed me at). *most* of the patches which apply to the current version apply to this new version too. Should I clone the util-linux- dir to util-linux-, or should I move it to util-linux ? Jun 14 11:42:17 Move it to util-linux. Jun 14 11:42:58 Cool, thanks pb_ Jun 14 11:46:50 So now I have a recipe for the later version, should I post it to the ML for discussion/application? Jun 14 11:48:41 Yes, please. Jun 14 11:49:23 If this is oe classic, send it to the openembedded-devel list. If this is oe-core, send it to the oe-core list. Jun 14 11:54:35 oe-core. Jun 14 12:17:04 Hi everybody Jun 14 12:54:32 RP__: the problem I had yestarday with the task was due its name not end with nativesdk. I renamed it and then it worked. Jun 14 12:54:49 otavio: ah, cool Jun 14 12:57:38 RP__: dunno why this is require Jun 14 12:57:46 *required* Jun 14 12:58:05 otavio: nativesdk.bbclass now only works magic on things it sees marked as nativesdk Jun 14 12:58:23 RP__: and this is done based on PN? Jun 14 12:58:32 otavio: yes Jun 14 12:58:42 otavio: It makes more sense in the native.bbclass case Jun 14 12:59:00 otavio: I'm trying to bring native.bbclass and nativesdk.bbclass into line with each other Jun 14 13:00:03 RP__: I see Jun 14 13:43:45 morning kergoth Jun 14 13:48:11 I'm having some problems to link my program when cross-compiling for the TI Netra Jun 14 13:48:33 it is a QT program using OpenGL without X11 Jun 14 13:49:11 do I need to include -lQtOpenGLE? Jun 14 13:49:46 http://groups.google.com/group/beagleboard/browse_thread/thread/af08e6df4cf72a64 mentions QtOpenGLE is not used by the examples Jun 14 13:50:32 whn I include it, I get some undefined reerence errors of libQtOpenGLE.so Jun 14 13:51:09 e.g.: ../sysroots/armv7a-none-linux-gnueabi/usr/lib/libQtOpenGLE.so: undefined reference to `QEglContext::configAttrib(int, int*) const' Jun 14 13:51:10 hi tartaturs Jun 14 13:51:57 kannerke use the precompiled packages Jun 14 13:52:19 dont know why he take the pain to compile qt himself on the beagle Jun 14 13:53:44 woglinde: which precompiled packages? Jun 14 13:59:37 angstroem? Jun 14 14:01:57 RP__: around Jun 14 14:02:59 RP__: if you add FEED_ARCH = ${BASE_PACKAGE_ARCH}" somewhere in your distro.conf you should be abale to reproduce the parsing error I am seeing Jun 14 14:03:38 khem: ok, I'll try that Jun 14 14:03:57 khem: like that, or with matching quotes? Jun 14 14:05:34 khem: hmm, it didn't work here Jun 14 14:06:25 If I add it to overrides too though... Jun 14 14:06:49 (and enable rm_work) Jun 14 14:09:44 Ah, I can understand the problem I think Jun 14 14:10:03 If you add FEED_ARCH into OVERRIDES and its "all", that causes problem Jun 14 14:11:10 Specifically, the rm_work_all task conflicts with rm_work Jun 14 14:12:27 hm, those perl changes seem to have hosed my TMPDIR somehow. Jun 14 14:13:19 heh..I missed the autofoo fixes btw Jun 14 14:13:58 oh well, probably about time I did a clean build anyway Jun 14 14:14:11 heh, we really need a new char for overrides, and/or overrides namespaces Jun 14 14:14:13 * kergoth yawns Jun 14 14:14:21 yeah Jun 14 14:15:07 still, what's FEED_ARCH doing in OVERRIDES anyway? that sems a bit on the bogus side. Jun 14 14:16:09 pb_: If you did manage to work around that parsing failure, rebuilding autoconf-native/automake-native would probably fix it if I'm guessing correctly Jun 14 14:16:33 pb_: I've never liked the idea. The reason is so you can do things like have armv7a specific overrides Jun 14 14:16:54 kergoth: agreed, just a question of how/when we'd do something like that... Jun 14 14:17:12 yeah, probably. I don't actually have a parsing failure at the moment, it's just that autom4te is looking for perl in the wrong place Jun 14 14:17:55 pb_: perl got moved into its own special path which means anything assuming it was in the sysroot needs to rebuild Jun 14 14:18:13 * RP__ hopes this will put some of the perl issues to rest, finally Jun 14 14:18:16 yeah Jun 14 14:18:34 I'll just blow the tree away and rebuild. Jun 14 14:18:51 gotta save my modified kernel tree first, though, be annoying to lose that. heh. Jun 14 14:19:45 meantime I'll work on webkit for a bit, and then when that gets too nauseating I will have a look at the buildbot thing. Jun 14 14:19:57 pb_: :) Jun 14 14:20:10 doesn't look like it should be too hard to set up from the quick glance I had earlier. Jun 14 14:20:16 * RP__ would like to know why builds are taking 15 mins longer :/ Jun 14 14:20:35 compared to when? Jun 14 14:20:50 pb_: A few days ago Jun 14 14:21:11 pb_: trouble is I had a sane result, I added a patch, got a bad one, reverted the patch and its still bad Jun 14 14:21:31 so I'm at a loss to explain the result :/ Jun 14 14:22:07 You can't even diff build times between recipes as it depends too much on system load Jun 14 14:22:15 We have a very chaotic system :( Jun 14 14:23:35 All the profiling says the patch I added should have improved things so I'm very confused. The baseline must have been bad or something else has crept in :/ Jun 14 14:29:16 rp urgs Jun 14 14:29:37 RP__: so, heh, the cache got bad somehow Jun 14 14:29:57 RP__: I'd be a little concerned here since it was a brand new checkout and all that Jun 14 14:30:12 (as in, total blank slate first time I ran bitbake there) Jun 14 14:30:25 Tartarus: I'm concerned but need more info :/ Jun 14 14:30:40 I can give you a git hash Jun 14 14:30:58 Tartarus: That doesn't tell me much :/ Jun 14 14:31:11 What do you need? Jun 14 14:31:20 Tartarus: A reproducer really :/ Jun 14 14:31:23 heh Jun 14 14:31:32 So I shouldn't have nuked the cache? :( Jun 14 14:31:51 Tartarus: it could have had some clues Jun 14 14:31:59 Bah, damnit Jun 14 14:32:18 Tartarus: I still wondering if its something to do with git-native on that machine Jun 14 14:32:29 Tartarus: Have you tried another build? Jun 14 14:33:11 RP__: kicking one now Jun 14 14:34:41 RP__: yeah, agreed, I have also noticed the build times are a bit variable. It is indeed rather hard to benchmark changes reliably, it'd be nice to figure out a way to fix that. Jun 14 14:37:11 hm, I'm still getting perl-native built as a dependency of pseudo. I had hoped that was going to go away with the chnages that just got landed. Jun 14 14:37:31 pb_: What version of tar is on your system? Jun 14 14:37:39 1.23 Jun 14 14:37:52 pb_: thats why. Update it to 1.24 and it should stop doing that Jun 14 14:38:57 ah. why does an outdated tar cause perl-native to be needed? Jun 14 14:39:08 (and why do we need tar 1.24 specifically?) Jun 14 14:39:29 pb_: It builds tar-replacement-native and roughly that needs gettext which needs perl Jun 14 14:39:38 crumbs, it's also building curl-native and openssl-native now. I don't think that used to nappen. Jun 14 14:39:42 s/nappen/happen/ Jun 14 14:40:03 and we need tar 1.24 as versions 1.18-1.23 are broken and can't cope with our sstate tarballs containing symlinks Jun 14 14:40:05 oh, for git-native I suppose. Jun 14 14:40:11 ah, drat, build failed. Jun 14 14:40:17 | make[1]: /home/pb/oe/build-giga/tmp-eglibc/sysroots/x86_64-linux/bin/perl: Command not found Jun 14 14:40:22 sux0r Jun 14 14:40:39 pb_: sstate packages from before? Jun 14 14:40:54 no, I nuked sstate_cache and tmp* Jun 14 14:41:24 * RP__ wonders if the confllict was 100% resolved Jun 14 14:41:37 that was git-native's compile stage failing, fwiw Jun 14 14:42:16 * RP__ wonders if he's screwed up resolving the merge conflict Jun 14 14:42:31 the perl that I have is in sysroots/x86_64-linux/bin/perl-native/perl Jun 14 14:42:41 Hi everybody, wow can I tell bitbake my application will be for host? by inheriting native class in bb file? Jun 14 14:43:02 which I guess is the right place, it seems that git is just looking for it in the wrong path Jun 14 14:43:04 pb_: what is it thats searching there? Jun 14 14:43:16 dunno, some crazy git thing Jun 14 14:43:20 | /home/pb/oe/build-giga/tmp-eglibc/sysroots/x86_64-linux/bin/perl Makefile.PL PREFIX='/home/pb/oe/build-giga/tmp-eglibc/sysroots/x86_64-linux' INSTALL_BASE='' Jun 14 14:43:20 | make[1]: /home/pb/oe/build-giga/tmp-eglibc/sysroots/x86_64-linux/bin/perl: Command not found Jun 14 14:43:20 | make[1]: *** [perl.mak] Error 127 Jun 14 14:43:25 is a bit more of the context Jun 14 14:43:43 $ cat meta/recipes-devtools/git/git.inc | grep OECONF Jun 14 14:43:43 EXTRA_OECONF = "--with-perl=${STAGING_BINDIR_NATIVE}/perl-native/perl --without-tcltk" Jun 14 14:44:17 pb_: Can you confirm you have that? Jun 14 14:45:37 ah, right, that's it Jun 14 14:45:52 I don't have that patch because I reverted to an older git to work around the earlier parse error Jun 14 14:46:00 and then I forgot to update git again once the perl thing was fixed Jun 14 14:47:03 let me try again then Jun 14 14:47:06 mgundes: likely, yes Jun 14 14:53:36 RP__: thanks Jun 14 14:56:56 hm, do we actually need the perl bits enabled for git-native? Jun 14 14:57:30 gnu-config-native and automake-native are both using perl-native-runtime now, which seems like an improvement, but perl-native is still needed by git-native (which is getting dragged in by gettext for some obscure reason) Jun 14 15:02:52 * ant_work marks the 3 LAKML threads about DTB appended to arm zImage for later reading Jun 14 15:08:33 How much space does your TMPDIR's occupy? I'm installing dualboot and need to set aside enough space for OE. Jun 14 15:23:53 rather depends what you're building. mine seems to be 38G but that is with several kernel trees. Jun 14 15:26:20 pb_: yes, it depends on how many machines/ kernels too Jun 14 15:26:40 pb_: thanks. I'm gonna compile Angstrom 2010.x for a Beaglish board Jun 14 15:39:25 running on a 64-bit, can I compile an SDK for a 32-bit? Jun 14 15:40:15 s/a //g Jun 14 15:43:35 tasslehoff: yes Jun 14 15:44:57 tasslehoff: SDKMACHINE, at least in oe-core Jun 14 15:51:21 ah. cool Jun 14 15:55:26 who had editing permissions on the oe WIKI "Category:Policy" page? Jun 14 15:55:42 (I need to get an additional policy listed there) Jun 14 15:55:55 http://wiki.openembedded.org/index.php/Commit_Patch_Message -- TSC approved commit and patch message guidelines Jun 14 15:58:08 nobody, it seems Jun 14 15:58:15 where does the base kernel source live in oe? Jun 14 15:58:32 I think RP has the privs in theory but last I heard he wasn't actually able to edit any pages Jun 14 15:58:33 heh.. I'll just have to ping someone later Jun 14 15:59:48 RP__: yes with matching quotes Jun 14 15:59:55 RP__: hmmm Jun 14 15:59:58 i'm trying to figure out how to use my kernel with oe - it looks like i need to make a series of patches against some base? Jun 14 16:00:20 tyco, if you want to use the oe-core kernel(s) and integrate it in.. then yes.. Jun 14 16:00:23 tyco: its in workdir Jun 14 16:00:33 it's based on configuration data and patches applied to the base.. Jun 14 16:00:47 otherwise the shortcut is just to provide your own kernel sources as part of a new recipe Jun 14 16:01:11 that sounds easier Jun 14 16:01:28 thanks Jun 14 16:01:29 it's easier.. but if you want to support it longer term, the patch/meta approach is easier Jun 14 16:01:33 that only works with oe-core though.. Jun 14 16:01:48 what is oe-core? Jun 14 16:01:50 (it's easier because you only manage the patches, not the whole kernel.. in my experience it's MUCH easier to update and keep things in sync) Jun 14 16:02:13 http://git.openembedded.org/cgit.cgi/openembedded-core/ Jun 14 16:02:24 this is the "future" of open embedded Jun 14 16:02:26 right, if i want to keep with the current kernel version Jun 14 16:02:31 it's still work in progress though.. Jun 14 16:02:54 RP__: also try to add ${FEED_ARCH} to OVERRIDES Jun 14 16:03:01 okay, i want a very simple system based on a ts7800 Jun 14 16:03:02 for kernel documentation on the oe-core kernel items and tooling: Jun 14 16:03:03 http://www.yoctoproject.org/documentation Jun 14 16:03:06 and see if you can reproduce it Jun 14 16:03:16 it's the BSP developers guide and Yocto Project Kernel Architecture and Use Manual Jun 14 16:03:18 to replace the static debian distro that the manufacturer provides Jun 14 16:03:53 tyco are you building product, or just hacking? if the later, then either will work for you Jun 14 16:03:54 is oe-core worth using at this point? what kind of issues should i expect iwht it? Jun 14 16:04:04 product Jun 14 16:04:20 if the former, the oe-core is what I would suggest -- unless your release date is within the next 6 months.. then you need to consider that it's still "in progress" development.. Jun 14 16:04:33 okay, thanks Jun 14 16:04:43 right now we're expecting to stabilize it and do a more formal release in the roughly september/october time frame.. Jun 14 16:04:57 i really just want a simple build system to allow me to control the rootfs and strip it down Jun 14 16:04:57 (we're in the middle of a transition right now) Jun 14 16:05:16 i see, how different will it be to use? Jun 14 16:05:22 tyco, if you have the time, I'd suggest starting with the oe-core... just keep in mind it might not be what you need right now Jun 14 16:05:28 the bitbake items and such are all the same.. Jun 14 16:05:52 oe-core has fewer recipes then oe-dev... (many of these are available in a new meta-openembedded layer -- not not all.. Jun 14 16:06:15 tyco: you should use 2011.03 release branch to start off Jun 14 16:06:23 i don't need much, no graphical util. just board support basically Jun 14 16:06:26 if you want a stable thing Jun 14 16:06:32 okay, that's what i am on currently Jun 14 16:06:43 oe-core is changing things a bit that instead of having one large repository of build instructions/recipes.. it's a much smaller subset.. easier to get started with (IMHO).. then you can add "layers" to it in order to specify distribution specific items, BSPs, etc.. Jun 14 16:06:45 depending upon how much crapo'la you can take you might use dev branches Jun 14 16:06:49 yes, 2011.03 is the last stable release Jun 14 16:07:03 if you need stable, thats where you want to be.. Jun 14 16:07:10 fray, that sounds sensible Jun 14 16:07:45 oe-core is expected to the basis of OpenEmbedded, Angstrom, Yocto, and other distributions moving forward... but as I said, we're still transitioning Jun 14 16:07:50 TS-7800 is arm9 cpu right ? Jun 14 16:07:58 yes Jun 14 16:08:22 the 4.6.0 gcc in oe-core is still having teething issues on ARM.. if you do try oe-core, I'd suggest using the gcc 4.5.1 instead Jun 14 16:09:21 looks like oe-core is moving fast, and there is only one branch. i think i will stick with the release for now Jun 14 16:09:50 thats very reasonable if you are working on product Jun 14 16:10:10 sounds like a good direction for it to be moving though Jun 14 16:10:35 ya, a lot of the folks think so, which is why we're doing it.. Jun 14 16:10:35 tyco: but you might not have feroceon support in oe toolchains Jun 14 16:10:47 but soft-float should owrk keep that in mind Jun 14 16:11:50 does it make sense to use the manuf.'s provided toolchain? Jun 14 16:12:05 since open protium also used to have orion board which having same core as yours and was supported by OE Jun 14 16:12:12 so I guess it should not be a problem Jun 14 16:12:30 you can plugin external toolchains Jun 14 16:12:45 someone I remember plugged in Marvell's toolchain few months back Jun 14 16:12:54 look into ml archive Jun 14 16:13:02 okay Jun 14 16:13:23 * khem heads off Jun 14 16:22:38 khem: Anything putting "all" in overrides is doomed to cause problems Jun 14 16:23:07 pb_: git-native needs certain perl modules not installed as part of normal perl on most systems :( Jun 14 16:23:31 groan Jun 14 16:24:35 so we can't just configure it --without-perl, I guess? Jun 14 16:25:14 git is made up of perl scripts.. ;) so "no" Jun 14 16:25:31 (it has more then JUST perl scripts, but a lot of it is perl) Jun 14 16:25:50 well, right, I guess what I was asking was: do we need the perl bits for what we do with git-native? Jun 14 16:25:59 afaik, yes Jun 14 16:26:11 afaik, if you just want to clone and check out, you only need the core exe (which I think is non perl) Jun 14 16:26:23 but maybe we need git-native for more than that, I dunno Jun 14 16:27:17 the kernel tooling uses branch and some other specialty clone tooling.. Jun 14 16:28:07 ...but I'm looking, and the few items I thought were still perl don't seem to be in the latest version Jun 14 16:28:42 I just checked, no perl IS used heavily still Jun 14 16:30:54 which bits are still perl? Jun 14 16:31:30 the ones that absolutely are: Jun 14 16:31:36 I just looked in /usr/lib/git-core on my desktop and it seems that only git-add--interactive, git-difftool and git-relink are perl Jun 14 16:31:43 maybe there are some others hidden away that I didn't spot Jun 14 16:32:32 git-add--interactive, git-am, git-archimport, git-cvs*, git-difftool, git-instaweb, git-relink, git-send-email, git-svn, Jun 14 16:32:37 So I should be able to compile an SDK in 64-bit Ubuntu 11.04, that can be used in 32-bit Ubuntu 10.10? Jun 14 16:32:51 all of the binaries also show up if I do a grep perl on them -- but I'm not sure fi they use perl or not Jun 14 16:33:18 git-relink and git-difftool are both used in various standard tasks.. Jun 14 16:33:39 git-am and git-send-email are used in a few tasks as well, but likely could be ignored Jun 14 16:34:44 which standard tasks are those? I just did "grep -r git-relink oe-core" and didn't find any hits except the FILES in git.inc Jun 14 16:34:56 same with difftool Jun 14 16:35:36 my understanding is that relink is used by the cloning operation when specific options are selected.. these options are used by the kernel tooling in order to save space Jun 14 16:35:57 difftool, I believe is used in the merging tools.. (but I may be wrong there) Jun 14 16:37:59 I'm trying it quick to see if any of the items are needed Jun 14 16:38:12 thanks Jun 14 16:38:31 rp, can you comment on the kernel tooling thing? Jun 14 16:39:19 guy who knows the kernel tooling isn't here.. he's likely at lunch Jun 14 16:41:36 perl-native will still be needed though, even if git doesn't need it anymore Jun 14 16:42:07 perl-native is needed by other -native tools (gettext?) and it's also needed to be built if you will use perl on the target Jun 14 16:42:43 gettext doesn't seem to depend on perl-native directly, only via git-native Jun 14 16:43:19 gnu-config-native and automake-native are now using perl-native-runtime, and I think that should also be true for most of the other native tools Jun 14 16:44:40 whats the bitbake command to show me what required perl-native? since it's still being required Jun 14 16:44:55 I use bitbake -g and look at the .dot files Jun 14 16:45:07 there might be an incantation to get bitbake to tell you directly, but I don't know what it is Jun 14 16:45:14 thats what I was looking for Jun 14 16:45:22 there is also an external tool that will show you the stuf as well Jun 14 16:45:58 hm, rpm-native is still depending on perl-native as well. I thought we put a stop to that. Jun 14 16:46:19 that and git-native appear to be the only users of perl-native in my build, at least Jun 14 16:46:42 What is the difference between meta-toolchain and meta-toolchain-sdk? Jun 14 16:47:17 oh, I bet rp's change to native class handling has defeated the DEPENDS thing in rpm.bb Jun 14 16:47:25 yes, I suspect it did Jun 14 16:49:27 so, anyway, if we could stop git-native needing perl (and fix rpm harder) then it looks like we could eliminate perl-native as a dependency for at least some images. no doubt there are still others that will go on needing it, of course. Jun 14 16:51:20 there was a change to make git use the host perl but on F15 stock perl is missing some bits required by git Jun 14 16:52:14 incandescant pb_'s question is.. do any of the perl components in git need to be there.. Jun 14 16:52:33 the answer is unclear to me this second.. I suspect some do, but I'm not sure Jun 14 16:53:03 It depends on how usable git-native needs to be Jun 14 16:53:13 ie folks using sysroot/.../usr/bin/git Jun 14 16:53:52 It would be interesting to see which bits of git are affected Jun 14 16:54:21 RP__: fray had a list, see above Jun 14 16:54:32 possibly not a totally comprehensive list, but at least a place to start Jun 14 16:54:40 RP__: I bet things like send-email need some amount of perl Jun 14 16:55:03 yeah. so the question is, do we care about having git-send-email work with git-native? Jun 14 16:55:10 Tartarus: but those are used from the running system Jun 14 16:55:15 * RP__ would say not Jun 14 16:55:22 I'd just check what the fetcher uses Jun 14 16:55:24 if there is a desire to have a git that is fully usable for random interactive hacking then I would think it probably belongs in some git-sdk kind of thing Jun 14 16:55:26 Tartarus: or ought to be Jun 14 16:55:28 * kergoth wonders if libgit2 has come along well enough yet to make a pygit2 fetcher viable Jun 14 16:55:31 The high level question is, do we want people to use git-native when host git is old/incomplete/etc Jun 14 16:55:38 RP__ it's the kernel tooling I'm concerned about.. Jun 14 16:55:40 Or just tell them to install a newer git Jun 14 16:55:43 the fetcher I believe is just clone Jun 14 16:56:14 Tartarus: I'd say to ask to install a newer one Jun 14 16:56:16 fray: mostly now but not all (ls-remote at least) Jun 14 16:56:25 fray: We probably need input from zedd Jun 14 16:56:28 yup Jun 14 16:56:40 Tartarus: especially because OE will work fine with the old one, except the user won't be able to send fix Jun 14 16:56:52 kergoth: "libgit2 uses waf as its buildsystem" aaargh run away Jun 14 16:56:54 otavio: right, you can clone but contiributing is harder Jun 14 16:57:03 Tartarus: in fact, depending on the format of the repo we might be depending on 1.6 already Jun 14 16:57:15 Tartarus: or 1.4, don't recall Jun 14 16:57:37 Tartarus: but OE works. That's what it matter. Jun 14 16:57:49 Tartarus: as pb_ said, we can provide an git-sdk or whatever Jun 14 16:58:07 Tartarus: or even git-native-sdk Jun 14 16:58:17 Sure we can, I'm asking if we want to neuter git-native like that, or not Jun 14 16:58:25 And be clear we're doing it Jun 14 16:58:31 vs just assuming no one uses it today Jun 14 16:58:35 People do Jun 14 16:58:37 Tartarus: but I think if we can reduce the build-deps then better Jun 14 16:58:43 Tartarus: it will be good for most people Jun 14 17:01:01 And I am unsure many people will be using a too old git on the development machine Jun 14 17:01:31 In fact, from the mails I see on mailing list most people use 1.7 or newer Jun 14 17:03:43 How many of them are people using git-native? ;) Jun 14 17:03:51 What is the difference between meta-toolchain and meta-toolchain-sdk? Jun 14 17:04:10 Tartarus: I doubt many. I think most people uses distro tools for this Jun 14 17:04:30 pb_, thanks for fixing up the members list Jun 14 17:04:53 sure, no problem Jun 14 17:04:58 * pb_ go home now Jun 14 17:04:59 later all Jun 14 17:21:50 RP__: so thats the issue I think angstrom puts FEED_ARCH into overrides and FEED_ARCH = BASE_PACKAGE_ARCH which is set to "all" Jun 14 17:22:18 RP__: can we use allarch instead ? Jun 14 17:22:22 FYI,, git-native won't building without code patches -- if perl isn't available Jun 14 17:30:04 khem: allarch will work Jun 14 17:41:22 otavio: FYI still working on these bbappends; got stuck on qt4-tools-nativesdk failing to build (for several reasons) Jun 14 17:41:59 I don't even think nativesdk needs these flags but it does explicitly build src/sql Jun 14 17:45:27 bluelightning: right Jun 14 17:45:31 bluelightning: no problem Jun 14 17:53:55 Is perl-native unbuildable for anyone else ? Jun 14 17:54:32 i think every single one of my builds is hosed right now, each for an entirely different reason Jun 14 17:54:38 * kergoth thinks today is Monday again Jun 14 17:54:45 RP__: ok I have posted the patch for it here http://patches.openembedded.org/patch/5815/ Jun 14 17:54:53 kergoth: good that I am not alone on that Jun 14 17:54:56 plz consider Jun 14 17:54:59 kergoth: That would be horrible. Jun 14 17:55:23 bitbake has gone a bit wonky I observe Jun 14 17:55:58 khem: I've been using bitbake master without issues since some days Jun 14 17:56:12 khem: but today's oe-core is unbuildable Jun 14 17:56:19 on one of my box I am getting this error I reported to bitbake-devel earlier Jun 14 17:56:25 intermittently Jun 14 17:56:31 I hate those kind of errors Jun 14 17:56:46 otavio: what error do u get Jun 14 17:56:46 getting an eglibc patch application failure on my oe-core angstrom build atm Jun 14 17:56:58 kergoth: hmm Jun 14 17:57:12 what changed Jun 14 17:57:27 perl-native build failure Jun 14 17:57:42 * khem checks how is his build going on Jun 14 17:58:28 hmm progressing steadily no hiccups Jun 14 17:58:42 you guys need to throw away your build boxes :) Jun 14 17:58:43 khem: when i hit that bitbake issue, i updated oe-core and it went away. seems like its metadata caused,s omehow Jun 14 17:58:45 which is worrisome Jun 14 17:58:49 dunno Jun 14 17:59:06 yeah I recloned bitbake Jun 14 17:59:10 and it went away for me Jun 14 17:59:24 may be some file permissions Jun 14 17:59:26 dunno Jun 14 17:59:32 otavio: have you updated oe-core in the last couple of hours? a whole bunch of perl-native related fixes went in Jun 14 17:59:40 bitbake is one tool we need to make sure gets well tested Jun 14 17:59:44 bluelightning: yes Jun 14 17:59:45 before patch is merged in Jun 14 17:59:53 it can create havocs Jun 14 17:59:57 bluelightning: and those "fixes" broke my builds heheh Jun 14 18:00:17 yes, if it makes any difference my existing builds were also broken Jun 14 18:00:29 bitbake patches should we sent to ml and let folks test them for a week or so before applying them I would say Jun 14 18:00:37 bluelightning: hehe it's nice to share the pain heehhe Jun 14 18:01:06 I've deleted tmp and started from scratch Jun 14 18:01:13 bluelightning: I am doing it Jun 14 18:01:23 bluelightning: in fact I have also removed sstate-cache Jun 14 18:01:34 which is not great to have to do :/ but I'm in the middle of fixing this qt4 stuff Jun 14 18:02:04 bluelightning: yes; qt4 is a nice thing to boost also because it has lacking behind oe-dev and oe-core Jun 14 18:03:25 bluelightning: are you already bringing the qt4-native recipe at this moment ? Jun 14 18:03:34 bluelightning: or left it to another set? Jun 14 18:03:53 otavio: I've left that for a separate exercise Jun 14 18:07:42 bluelightning: I am not depends on this yet so for me it is not (yet) urgent Jun 14 18:07:51 bluelightning: rest of qt4 is indeed more important Jun 14 18:08:16 bluelightning: specially because it will reduce the delta a lot (between oe-core and meta-oe) Jun 14 18:08:30 otavio: right, the tidier these recipes are the better Jun 14 18:08:40 bluelightning: indeed Jun 14 18:09:05 bluelightning: i am working now at meta-toolchain that uses the qt4 recipes and so I ought to be putting fixes for those soon to Jun 14 18:09:26 otavio: ok, great Jun 14 18:10:00 otavio: btw I notice we have qt4-tools-sdk in meta-oe as well as qmake2 - do we need these? Jun 14 18:10:30 qmake2 is not used AFAICT and qt4-tools-sdk should be obsoleted by qt4-tools-nativesdk (when the latter is building successfully that is) Jun 14 18:10:56 bluelightning: I guess not; qmake2 will be built on qt4-tools Jun 14 18:11:08 yes Jun 14 18:11:12 bluelightning: and then it will turn into qt4-native later on Jun 14 18:11:58 bluelightning: and the build time difference doesn't justify to split qmake from the rest. Specially because most packages that use qmake depends on qt4 anyway Jun 14 18:12:25 otavio: ok, I will include separate patches to remove these from meta-oe then Jun 14 18:12:35 * bluelightning leaves his builds running and heads home Jun 14 18:24:02 anyone around yet that has the ability to edit the Policy listing on the OE wiki? Jun 14 18:25:05 mm.. I have login but not sure about rights Jun 14 18:25:14 what changes you need there? Jun 14 18:25:24 Need to get the new commit and patch guidelines linked there Jun 14 18:25:32 http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines Jun 14 18:25:48 but I don't have editing priveleges on Category:Policy Jun 14 18:26:00 ah.. Jun 14 18:26:10 well, khem or ka6sox-away may help iirc Jun 14 18:26:37 page was last edited in 2008 by Laibsch Jun 14 18:26:46 (when the contents were locked down) Jun 14 18:28:20 Nos it fails with | /home/otavio/hacking/el/tmp-eglibc-eglibc/sysroots/x86_64-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.6.0/ld: cannot find -lm Jun 14 18:30:44 cbrake: ping Jun 14 18:34:18 khem: any idea about the gcc build failure? it is gcc-runtime that fails to build (4.6.0-r3) Jun 14 18:38:14 * otavio is reverting to previous oe-core checkout to get his work going Jun 14 18:40:50 ok.. the Command and Patch Message Guidelines are posted Jun 14 18:41:00 email coming out shortly... Jun 14 18:44:57 hmm.. anyone here from Milan? I have a question about a local electronics supplier Jun 14 18:46:09 * tasslehoff repeats himself Jun 14 18:46:11 So I should be able to compile an SDK in 64-bit Ubuntu 11.04, that can be used in 32-bit Ubuntu 10.10? Jun 14 18:48:51 tasslehoff: in theory oe-core supports this, yes Jun 14 18:48:57 Probably more than theory even Jun 14 18:49:57 Tartarus: hope so. and I have a feeling I soon need to find out what this oe-core is :) Jun 14 18:50:56 gm Jun 14 18:51:39 I tried using a fresh checkout of oe-core Jun 14 18:51:50 found a post explaining it, but I'm unsure if it means that the stuff from oe-core is found in my org.openembedded.dev. Jun 14 18:51:53 (using the angstrom script) Jun 14 18:52:33 My first build attempt fails with: Pseudo is not present but is required, building this first before the main build Jun 14 18:52:40 and a return to the command prompt Jun 14 18:53:28 hard to believe I screwed up a 5 line process :-) Jun 14 18:53:38 has anyone else encountered this? Jun 14 19:02:52 For those having problem with oe-core builds, c3d317014f417ca895458b797afdf6c40e5b5a57 seems like a safe bed for now. Jun 14 19:06:52 otavio: I guess you disabled libm in eglibc Jun 14 19:07:16 khem: I didn't touch it Jun 14 19:07:24 config knob unfun? Jun 14 19:07:24 otavio: What does your DISTRO_FEATURES look like Jun 14 19:07:30 khem: it were building fine before Jun 14 19:07:31 Tartarus: yupp Jun 14 19:07:35 khem: let me check Jun 14 19:07:40 otavio: yes I know Jun 14 19:07:56 otavio: distro's now need to select features Jun 14 19:08:01 khem: So we failed to do this in a way that wouldn't horribly break folks or that's expected breakage that distros are going to need to recheck stuff? Jun 14 19:08:21 Tartarus: I would have expected to enable all features by default Jun 14 19:08:28 as folks have been doing that anyway Jun 14 19:08:39 but something might have slipped in Jun 14 19:08:44 k Jun 14 19:08:44 we will find out Jun 14 19:09:11 * Tartarus hands khem the asbestos pants Jun 14 19:09:12 sometimes you have DISTRO_FEATURES enabled and something might have been missing Jun 14 19:09:20 Tartarus: heh Jun 14 19:09:25 I am taking heat today Jun 14 19:09:52 * khem out to lunch Jun 14 19:09:58 khem: meta/conf/distro/ossystems-minimal.conf:DISTRO_FEATURES = "ipv4 ipv6 alsa pci largefile" Jun 14 19:10:20 you should prolly use += Jun 14 19:10:41 khem: which one enables m? Jun 14 19:22:41 yeah, I got bitten by that missing libm thing as well Jun 14 19:22:53 it seems that if you define a custom DISTRO_FEATURES you need to make sure it includes DISTRO_LIBC_FEATURES. Jun 14 19:23:06 otherwise, you get everything switched off in eglibc, doh Jun 14 19:24:11 Tartarus: hello Jun 14 19:24:36 cbrake: I see testing-next didn't happen last week. Going to this week tho, right? :) Jun 14 19:24:36 hi cbrake Jun 14 19:24:57 pb_: Hi Phil Jun 14 19:25:20 Tartarus: :-) yeah, we need to come up with a testing plan again, or just leave it up to Yocto Jun 14 19:25:39 Yeah, there's that too Jun 14 19:25:43 and what to do about reporting Jun 14 19:25:57 I've been doing the same matrix as before and keeping an eye out for new breakage I can fix Jun 14 19:26:05 (and I need to find the time to migrate that stuff to handle oe-core too) Jun 14 19:26:24 Tartarus: do you think oe-core is ready for a matrix of tests? Jun 14 19:26:45 Tartarus: or should we continue to focus on openembedded? Jun 14 19:26:49 'a'? Sure, same as the old one? no Jun 14 19:26:59 I think we need to get to focusing on oe-core Jun 14 19:27:10 and distro folks that haven't already need to start their distro layer Jun 14 19:27:22 (and that means "distro-less" testing as part of the matrix) Jun 14 19:27:26 Tartarus: that is my thought (focus on oe-core) Jun 14 19:27:32 khem and I have already got a test setup for oe-core that builds it in 22hrs Jun 14 19:27:46 and can regress it constantly Jun 14 19:27:51 ka6sox-away: Can you shoot that my way please? Jun 14 19:28:00 or wiki it :) Jun 14 19:28:05 I'll let khem shoot that your way. Jun 14 19:28:14 he has the scripts he used. Jun 14 19:28:18 khem: copy me as well Jun 14 19:28:46 but we use an SSD to make that happen in 22hrs Jun 14 19:29:05 Yeah, we'll see what the setup here takes Jun 14 19:29:18 shouldn't be an issue Jun 14 19:29:20 thoughts on if its worth trying to get multiple users involved in a testing effort again? Jun 14 19:30:02 it seems like we found a fair number of issues with the testing effort in the past (various workstation distros, etc) Jun 14 19:30:16 yeah, we need to make it easy for folks to test stuff too Jun 14 19:30:23 on whatever set of layers they're using Jun 14 19:30:48 Tartarus: what are you using for project setup for oe-core + layers? Jun 14 19:30:57 if we are already testing the 5 arches of oe-core what else would you want to test? meta-oe? Jun 14 19:31:17 ka6sox-away: yes, meta-oe + various distros Jun 14 19:31:17 ka6sox-away: whatever is needed to provide the components that people need Jun 14 19:31:24 Or at least someone wants to be :) Jun 14 19:31:36 cbrake: We're still playing around Jun 14 19:31:46 * Jay7 may setup nightly builds Jun 14 19:31:58 I've been using koen's setup-scripts repo, kergoth has something based on that iirc, but a bit different Jun 14 19:32:00 Tartarus: I'm still using git submodules, but most people don't like that mechanism as well as I do Jun 14 19:32:05 but it should complete in 8 hrs Jun 14 19:32:50 Tartarus: for tested branches, git submodules would be nice as it could pull a known set of modules locked down to specific has versions Jun 14 19:32:54 cbrake: I don't think anyone likes using anything 'raw' Jun 14 19:33:32 I was hoping to make buildbot take unsolicited reports but after creating an event handler that only reports success/failure + log for a package of the build. Jun 14 19:33:57 so instead of every step..every package of a full build. Jun 14 19:34:09 ka6sox-away: that sounds ideal Jun 14 20:00:53 03Koen Kooi  07org.openembedded.dev * r6d7afa5200 10openembedded.git/recipes/x-load/x-load_git.bb: Jun 14 20:00:53 x-load git: 1.5.0 sorts lower than 1.44ss, so bump PE Jun 14 20:00:53 Signed-off-by: Koen Kooi Jun 14 20:06:54 cbrake: i use submodules too, works well enough Jun 14 20:07:16 the problem with submodules is the maintenance of the tags.. they are a good way to put together non-changing content.. Jun 14 20:07:37 but as things evolve, you have to maintain the submodule ids... and that has proven difficult for people Jun 14 20:07:46 as long as its convenient to update i don't see an issue. the user can always pull it down and update them Jun 14 20:07:48 it's much easier to just pull from a branch from various repos Jun 14 20:08:07 git submodule foreach git checkout master; git submodule foreach git pull Jun 14 20:08:14 if subgits could say "I want this branch" instead of "this commit".. it would be a whole hell of a lot better IMHO Jun 14 20:08:32 'er.. submodules, not subgits Jun 14 20:08:45 'repo' used to do just that, and they ended up changing their minds, now it'll be based on submodules Jun 14 20:08:48 heh Jun 14 20:13:28 kergoth: is repo moving to submodules? Jun 14 20:13:58 last i read it was going to in the long term, but i don't monitor its development that closely Jun 14 20:23:21 hello, i have a vala problem, during build of shr image: /home/nschle85/shr-build/shr-unstable/tmp/sysroots/x86_64-linux/usr/bin/valac -C --basedir .. --vapidir ../data --vapidir ../vapi --pkg glib-2.0 --pkg gio-2.0 --pkg libgisi --pkg posix --pkg posix-ext --header gisicomm.h --library gisicomm-0.0 gisicomm.vala Jun 14 20:23:21 | posix-ext.vapi:7.5-7.30: error: `Posix' already contains a definition for `INET_ADDRSTRLEN' Jun 14 20:23:21 | const int INET_ADDRSTRLEN; Jun 14 20:23:46 can anybody help ? Jun 14 20:23:57 wait for mickeyl Jun 14 20:24:44 but that can last a while Jun 14 20:25:24 woglinde: who else may help ? Jun 14 20:34:01 ls Jun 14 20:34:07 whops Jun 14 20:58:23 cbrake: my setup is using angstrom top of oe-core right now Jun 14 21:02:19 khem: ok, thanks Jun 14 21:57:11 03Stanislav Brabec  07master * rf8a2cccaca 10openembedded.git/recipes/navit/navit_svn.bb: Jun 14 21:57:11 navit: Update to SVN version 4530. Jun 14 21:57:11 Signed-off-by: Stanislav Brabec Jun 14 21:58:27 ~lart citrix for binary client blob Jun 14 21:58:27 * ibot plops citrix into a giant vat of herring for binary client blob Jun 14 21:59:40 03Stanislav Brabec  07master * rea92543e4b 10openembedded.git/recipes/epos/ (3 files in 2 dirs): Jun 14 21:59:40 epos: New recipe for new package (text-to-speech). Jun 14 21:59:40 Signed-off-by: Stanislav Brabec Jun 14 22:01:48 03Tom Rini  07master * r3c2fb5ab3c 10openembedded.git/recipes/lttng/ust_0.8.bb: Jun 14 22:01:48 ust: Drop 0.8 Jun 14 22:01:48 This is unpinned and has problems on certain architectures. Jun 14 22:01:48 Signed-off-by: Tom Rini Jun 14 22:01:58 03Tom Rini  07master * r2a430776fe 10openembedded.git/recipes/lttng/ (ust.inc ust/ustd.init): Jun 14 22:01:58 ust.inc: Fix ustd.init for 0.12 Jun 14 22:01:58 With 0.12, how ust daemon needs to be started changed, update the initscript Jun 14 22:01:58 for it. (While in here, Tom dropped S assignment from ust.inc). Jun 14 22:01:58 Signed-off-by: Andrew Gabbasov Jun 14 22:01:58 Signed-off-by: Tom Rini Jun 14 22:06:24 hm.. seems mentor.com have lot of russian employees ;) Jun 14 22:36:46 woglinde_: hmm, sound like libgisi should be bumped in OE Jun 14 22:36:57 i'll take a look tomorrow Jun 14 22:43:05 he mickeyl Jun 14 22:43:07 grats Jun 14 22:43:09 *g* Jun 14 22:43:13 and welcome to the club Jun 14 22:45:00 yeah mickey|daddy, congrats! Jun 14 23:25:21 03Andrea Adami  07org.openembedded.dev * r8a987fbee5 10openembedded.git/recipes/klibc/ (20 files in 2 dirs): Jun 14 23:25:21 klibc: move to 1.5.23 Jun 14 23:25:21 * retain compatibilty patches for older kernels Jun 14 23:25:21 Signed-off-by: Andrea Adami **** ENDING LOGGING AT Wed Jun 15 02:59:57 2011