**** BEGIN LOGGING AT Wed Dec 14 02:59:57 2011 Dec 14 03:24:05 hi i am facing the same problem as this fellow http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/29495.aspx Dec 14 03:24:14 wonder anyone could advise? Dec 14 03:36:32 so does anyone know if CVS works via socks5 proxy w/o a wrapper? Dec 14 03:36:45 or explictly via oe-core Dec 14 03:37:57 pretty sure it doesn't, at least I always used to have to use an LD_PRELOAD proxy lib for it back at TI Dec 14 03:37:59 * kergoth shrugs Dec 14 03:40:59 anyone know how to pass initramfs(.cpio.gz) separately into the kernel? Dec 14 03:58:33 anyone know how to pass initramfs(.cpio.gz) separately into the kernel? Dec 14 04:09:35 kaylessa: Depends on your bootloader. Dec 14 04:10:34 mine is a uboot Dec 14 04:10:43 i tried passing initrd=0xXXXXXXXX Dec 14 04:10:56 setenv bootargs initrd=0xXXXXXXXX Dec 14 04:10:59 and it doesnt work Dec 14 04:11:11 if i embeded .cpio.gz with my kernel it work Dec 14 04:11:21 serparating it doesnt :( Dec 14 04:11:38 wonder if anyone could help Dec 14 05:14:08 I working behind http proxy when I Build It failed beacause it try to download via svn://. How can i change to http:// instead of svn:// **** ENDING LOGGING AT Wed Dec 14 06:20:29 2011 **** BEGIN LOGGING AT Wed Dec 14 06:22:15 2011 Dec 14 08:55:36 morning all Dec 14 09:15:56 mornin Dec 14 09:16:22 I'd like to test the patch khem posted to the ML (Let G++ relocate gxx-include-dir when using --sysroot option). What's the best/easiest way to apply a patch from the ML? Dec 14 09:24:41 tasslehoff: probably create a new branch (git checkout -b testbranch) then save the email and just "git am" it Dec 14 09:25:14 assuming it applies cleanly it will become a commit on that branch Dec 14 09:25:29 bluelightning: it did (saved as an eml) Dec 14 11:27:14 03Steffen Sledz  07org.openembedded.dev * rc75eac282c 10openembedded.git/recipes/openjdk/openjdk-6-common.inc: Dec 14 11:27:14 openjdk: fix problem on build hosts with linux kernel 3.x Dec 14 11:27:14 see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072341 Dec 14 11:27:14 Signed-off-by: Steffen Sledz Dec 14 11:27:24 03Steffen Sledz  07org.openembedded.dev * r311422db18 10openembedded.git/recipes/icedtea/icedtea6-native.inc: Dec 14 11:27:24 icedtea6-native: fix problem on build hosts with linux kernel 3.x Dec 14 11:27:24 see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072341 Dec 14 11:27:24 Signed-off-by: Steffen Sledz Dec 14 11:39:45 Compiling oe-core seems much slower on my setup than compiling oe-classic. Is that a fact? Dec 14 11:41:09 tasslehoff: my colleagues and me had the same impression :( I did not do any real benchmarking though Dec 14 11:45:23 Jin^eLD: ok. I'll see if I get the time too look into it Dec 14 11:45:51 tasslehoff: I had the impression that pseudo eats up a lot of cpu time, at least on my system it's often dangling around 30%, sometimes even more Dec 14 11:46:45 Jin^eLD: that's what I see here as well Dec 14 11:46:52 same here Dec 14 11:47:13 well, that'd be the reason for slower builds I guess... Dec 14 11:47:14 ? Dec 14 11:47:57 the overall workflow takes a lot of time (for example, I used to rm stamps/run.linux_do{compile,deploy} bitbake virtual/kernel -- much slower now). Dec 14 11:49:02 if you guys can articulate these in the form of an email a bit more descriptively I'm sure we can try to improve things... Dec 14 11:54:17 Hi everybody Dec 14 11:54:50 When I compile and install some of my applications, there is an extra directory named ".debug" Dec 14 11:55:33 These directories are added to rootfs and therefore I get bigger rootfs image Dec 14 11:56:11 Does anybody know why is those directories created and how can I prevent them to be added to rootfs image Dec 14 11:56:38 I will appreciate if anyone tells me the reason Dec 14 11:57:13 mgundes: I assume it happens with your self-made recipes, probably your FILES_${PN}-dbg does not list those .debug directories for some reason Dec 14 11:57:55 or you put stuff in non standard places, then you'd have to add those places in your recipe so the debug files land in the debug package Dec 14 11:59:49 yes, they are my own recipes Dec 14 12:00:11 I added at the end of recipes these two lines: Dec 14 12:00:17 PACKAGES = "${PN}" Dec 14 12:00:19 FILES_${PN} = "/*" Dec 14 12:00:30 to include files to the rootfs Dec 14 12:00:31 well that kind of explains it then :P Dec 14 12:00:52 why did you do that anyway? Dec 14 12:01:33 because it did not add files to the rootfs Dec 14 12:01:50 then I tried to tell add everything by those lines Dec 14 12:01:50 if you install your stuff in standard locations, it will be picked up automatically; if you have something in non standard locations you can manually add it via FILES_${PN} += "/blah" (and for -dbg respectively) Dec 14 12:02:31 what is the standard location? what do you mean by standard location? Dec 14 12:02:34 and please remove PACKAGES = "${PN}", I don't think its a good idea Dec 14 12:02:36 PN and PR Dec 14 12:02:37 ? Dec 14 12:02:48 no, I mean, if you install your binaries to /usr/bin for example Dec 14 12:03:04 taht's a "standard location" on the rootfs, i.e. how it is used to be done on linux Dec 14 12:03:34 hm ok Dec 14 12:03:41 OE picks up things taht are in those "standard" dirs automatically Dec 14 12:03:47 so I dont need that two line then, right? Dec 14 12:04:45 if you install something to, like, /myweirddir/additionalstuff then you'd have to add this custom location to the FILES_${PN} variable, and if there is some debug stuff in this dir, then add the debug stuff to FILES_${PN}-dbg Dec 14 12:05:14 you don't need them, no Dec 14 12:06:34 mgundes: for the default definitions of these things have a look in conf/bitbake.conf Dec 14 12:06:35 ok but I still could not understand how .debug director is created :) Dec 14 12:07:01 I don't have .debug directory anywhere but I can see in package directory and in rootfs Dec 14 12:07:14 mgundes: it's more than likely part of the build process for your application Dec 14 12:07:27 mgundes: see package.bbclass Dec 14 12:07:48 hm, ok I will check bitbake.conf and package.bbclass Dec 14 12:07:53 thank you all Dec 14 12:07:57 appreciated Dec 14 12:09:46 bluelightning: yeah. so far "it seems to take more time to compile than before" is the most detailed report I've got :) Dec 14 12:33:54 is there a change in gcc 4.6 (core + meta) between Dec 2 and Dec 12, which can cause it to emit one 'ldr' instead of 4 'ldrb' on a __packed data structures (armv7-a)? Dec 14 12:43:59 ensc|w: maybe, ask "khem" when he is online, but in the meantime please look the cgit.openembedded.org logs for gcc 4.6 Dec 14 12:44:16 ensc|w: is it giving problems? Dec 14 12:44:23 I see only the costs patch Dec 14 12:44:43 u-boot segfaults with gcc > Dec 12 due to an alignment error Dec 14 12:45:03 ensc|w: what architecture or board? Dec 14 12:45:11 it's omap Dec 14 12:45:41 (I know cpu should handle misalignment, but it might be possible that the A bit is not set) Dec 14 12:45:50 exactly Dec 14 12:46:33 gcc does indeed assume that the architecture can handle unaligned access on armv6+ now. I do not know when that was introduced exactly, probably by some linaro patches. Dec 14 12:47:01 it has been giving a few problems here and there on systems where that bit is not set, as gcc assumes it is... Dec 14 12:47:08 I know that splitting a ldr into 4 ldrb caused problems with gcc 4.6 (afair, somewhere in linux usb code) Dec 14 12:47:23 I wonder whether this behaviour has been reverted Dec 14 12:48:18 See if "-fno-unaligned-access" is used or not. Also, on ARM "-fconserve-stack-space" is a flag that introduces unalignment if allowed. Dec 14 13:41:58 any expert on initramfs? Dec 14 13:42:11 hi Dec 14 13:42:32 hmm any idea when embedding .cpio into my kernel works Dec 14 13:42:43 but separating it doesnt work? Dec 14 13:43:00 i am trying to load it separately into the memory Dec 14 13:51:06 I'm trying to compile a java program, bitbake tells me that there are serveral providers for java_runtime (cacao, jamvm, openjdk) and suggests me to set a PREFERRED_PROVIDER Dec 14 13:51:11 how do I do that? Dec 14 13:55:33 taedium: add PREFERRED_PROVIDER_java-runtime = "openjdk" Dec 14 13:55:50 assuming it is "java-runtime" it's talking about Dec 14 13:56:02 add it to your conf/local.conf I mean Dec 14 13:58:19 ok Dec 14 13:59:01 I also have a problem with the javac compiler Dec 14 13:59:41 the one which is installed in build/arm/tmp/sysroots/x86_64-linux/usr/bin/javac Dec 14 14:00:17 it gives me compile errors, and I guess there are compatibility versions Dec 14 14:00:34 any idea how to load .cpio.gz separately with kernel for boot up? Dec 14 14:01:26 if I set the provider to openjdk, do you think it I will solve the problem? on my machine the same code compiles with no problems and I use openjdk Dec 14 14:03:20 when using systemd, is the symlinks to my services supposed to be created at build time or at first boot? I've added WantedBy=multi-user.target, but have to enable them manually http://pastebin.com/PcsXH2Dq Dec 14 14:11:26 tasslehoff: in do_rootfs Dec 14 14:11:42 just checked, works here Dec 14 14:12:10 hmm does using .cpio.gz need to pass root= ? Dec 14 14:13:16 or just initrd= is enough? Dec 14 14:14:43 JaMa: should I find it in the image-dir of the work-dir as well? Dec 14 14:15:20 JaMa: I mean: build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/pd-app-1.0-r4/image Dec 14 14:24:29 kaylessa, hi it depend if it's for initrd or initramfs, see the documentation in the kernel that I pointed you to the other day Dec 14 14:24:50 i already read that Dec 14 14:24:52 still fail Dec 14 14:24:55 ok Dec 14 14:24:57 i read from top to bottom Dec 14 14:25:00 from bottom to top Dec 14 14:25:15 hmmm Dec 14 14:25:22 you use uboot right? Dec 14 14:25:26 i dont understand why combining it works Dec 14 14:25:31 but separating doesnt Dec 14 14:25:36 yup uboot Dec 14 14:25:50 do you know a quick way to generate an initrafs within the current core-based oe? Dec 14 14:26:00 not for x86 but for arm Dec 14 14:26:11 for instance where's kexecboot-image Dec 14 14:26:18 or similar initramfs images Dec 14 14:26:30 another issue: trying to compile a cpp program, it gives error about size_t being not defined, and I don't understand why Dec 14 14:26:48 i am using this tutorial Dec 14 14:26:52 http://www.3open.org/d/oe/build_kernel_with_inline_initramfs Dec 14 14:27:01 instead of mtd-utils Dec 14 14:27:03 i am using just helloworld image Dec 14 14:27:09 kaylessa, try using oe, I tried by hand and had some issues in the past Dec 14 14:27:18 i used OE to build Dec 14 14:27:32 ok Dec 14 14:27:36 i followed the tutorial step by step Dec 14 14:27:39 and i got it working Dec 14 14:27:49 but i try to separate them out Dec 14 14:27:51 it doesnt Dec 14 14:27:55 yes but not the way you wanted.... Dec 14 14:28:14 is the tutorial correct? Dec 14 14:28:21 seem for the old oe Dec 14 14:28:41 seems like everything is old Dec 14 14:29:06 kaylessa, what oe do you use? openembedded-classic or the core based one? Dec 14 14:29:14 JaMa: gotta run, so don't bother replying (yet) :) Dec 14 14:29:23 core based one i guess? Dec 14 14:29:38 i followed the guide at openembedded wiki Dec 14 14:29:42 ah? Dec 14 14:30:02 there was some dicussion on the ml about that guide, last time I looked it pointed to oe classic Dec 14 14:30:08 what did you clone exactly? Dec 14 14:30:11 (git clone) Dec 14 14:30:37 git clone Dec 14 14:30:40 yup Dec 14 14:30:44 git clone git://git.openembedded.org/openembedded Dec 14 14:30:52 that's the old openembedded Dec 14 14:31:01 so the tutorial you saw applies to it Dec 14 14:31:06 o.O Dec 14 14:31:20 ok just i am correct then Dec 14 14:31:23 i use old OE and old tutorial Dec 14 14:31:26 yes Dec 14 14:31:56 kinda hard to find proper documentation Dec 14 14:32:00 its like everywhere Dec 14 14:32:12 no idea which is old or new Dec 14 14:32:32 I'll try to find an initramfs within the newer oe Dec 14 14:33:17 ok Dec 14 14:33:57 hmmm Dec 14 14:33:59 there is core-image-minimal-initramfs.bb Dec 14 14:34:07 but it seem for livecd Dec 14 14:35:09 let me see if i have that Dec 14 14:36:00 nope i dont Dec 14 14:36:10 that's because you have the old oe Dec 14 14:36:34 does it really matter? Dec 14 14:36:46 i have the .cpio.gz file Dec 14 14:36:55 for me it matters Dec 14 14:36:55 i just need to tell the kernel where to look for it Dec 14 14:37:04 I want to try Dec 14 14:37:09 through initrd Dec 14 14:37:14 and I don't have a working oe-classic Dec 14 14:37:20 i dunno what i am saying is correct Dec 14 14:37:26 ahhh who can i ask Dec 14 14:37:51 maybe ask in the mailing list for your problem or wait for me to build an shr-initramfs-image that I just created Dec 14 14:38:07 how to ask in mailing list? Dec 14 14:38:23 is there any way i can seek help beside coming to this channel? Dec 14 14:38:46 yes the mailing list Dec 14 14:38:59 how i go about doing it? Dec 14 14:39:01 basically suscribe to the mailing list Dec 14 14:39:05 not openembedded core Dec 14 14:39:09 but the normal one Dec 14 14:39:09 where? Dec 14 14:39:13 since you use oe classic Dec 14 14:39:30 http://www.openembedded.org/wiki/Mailing_lists Dec 14 14:39:43 openembedded-devel@lists.openembedded.org Dec 14 14:39:52 suscribe Dec 14 14:39:58 wait for the confirmation mail Dec 14 14:40:03 click on the confirmation link Dec 14 14:40:10 and then you can send a mail to the list Dec 14 14:40:45 ok can Dec 14 14:40:49 guess i shall wait Dec 14 14:40:58 thanks GNUtoo Dec 14 14:41:06 maybe suscribe and wait before sending the mail Dec 14 14:41:14 do u see ant_work recently? Dec 14 14:42:30 i will come back tmr Dec 14 14:42:35 thanks guys ! Dec 14 14:44:10 hi ericben Dec 14 15:08:37 GNUtoo: hi, got h/w already? :) Dec 14 15:44:16 hi GNUtoo Dec 14 16:10:20 what exactly should be listed in PROVIDES if at all, a binary name that is provided, or a package name that is being replaced by the new package? Dec 14 16:11:02 neither. Dec 14 16:11:07 you're mixing up PROVIDES and RPROVIDES Dec 14 16:11:42 also, PROVIDES is always defined, it includes ${PN}, ${PN}-${PV}, and ${PN}-${PV}-${PR} Dec 14 16:13:01 ok and for RPROVIDES? Dec 14 16:14:39 rprovides isn't automatically defined, but it doesn't have to be, the package name of the package is implicitly provided Dec 14 16:15:09 hmm Dec 14 16:15:24 I thought I'd need it when a package providing same funcitonality changes name or something Dec 14 16:15:37 it could be used for that, yes Dec 14 16:16:25 if you want to learn about provides and conflicts, i'd suggest reading the debian/dpkg policy manual, it has some good information on the subject. I'm sure the rpm docs cover it too from that side of things Dec 14 16:16:33 opkg behaves like dpkg, so it's covered by the former Dec 14 16:16:53 ok thx Dec 14 16:17:13 always remember that with runtime stuff, the vars just get translated and emitted into the binary package metadata. how its handled from there is up to the package manager :) Dec 14 16:17:41 indeed :) and in case of opkg that can sometimes be a little unexpected Dec 14 16:18:38 heh, opkg can behave unexpectedly in quite a few circumstances :| better than nothing, but it's scope is limited, so its capabilities are limited, and not always 100% consistent with dpkg, but it tries Dec 14 16:20:02 hmm Dec 14 16:20:11 * kergoth looks at the last access times of his oe DL_DIR Dec 14 16:20:42 wonder if this would be a good way to trim down old unused stuff. set up a cron job to delete downloads that haven't been accessed in 6+ months or something Dec 14 16:20:52 assuming the fs was mounted with access time tracking anyway Dec 14 16:20:58 * kergoth thinks Dec 14 16:22:45 kergoth: maybe also deleting older versions of sources with multiple versions. E.g., delete foo-1.0 and foo-2.0 when you have foo-3.0, foo-2.0 and foo-1.1. Dec 14 16:22:55 don't we have tool that reports sources that was not required anymore by recipes? Dec 14 16:23:04 s/foo-1.1/foo-1.0/ Dec 14 16:23:31 i.e. compare parsed metadata with sources directory listing Dec 14 16:23:35 mario-goulart: that's nontrivial. exactly what magic algorithm are you going to use to extract a version number from a filename? Dec 14 16:23:51 kergoth: good question. :-) Dec 14 16:24:43 the recipes know where the version fits into the filename, but we don't have code to take a string with variable references and convert it into a pattern to match something. that could be interesting though Dec 14 16:24:52 sort of like a bitbake version of scanf vs printf Dec 14 16:24:55 I see. Dec 14 16:25:25 kergoth: I guess it would not be that hard to write a script that ran "bitbake -e -b ... | grep ^SRC_URI" on each recipe and parsed the output. Dec 14 16:26:46 yeah, true Dec 14 16:28:13 but yeah, just doing it based on atime seems reasonable enough as well Dec 14 16:28:48 I'd hate to remove things that might still be needed, and given the number of bsps and layer combinations and the like that get built, its hard to know exactly what that is Dec 14 16:29:08 on the other hand, things growing without bound is not ideal :) Dec 14 16:29:49 well, removing too many files from the DL_DIR is not a massive crisis, you can always download them again Dec 14 16:30:20 absent reliable atimes, you could just have an algorithm that picked a file at random to delete when the directory grew over a certain size Dec 14 16:30:45 assuming upstream hasn't removed them, sure :) Dec 14 16:30:51 * kergoth mutters Dec 14 16:31:03 course thats what mirrors are for :) Dec 14 16:31:27 right :-) Dec 14 16:32:20 * kergoth plays around with python-dateutil's "relativedelta" for relative times -- if atime < (date.now() + relativedelta(months=-6)): Dec 14 16:53:56 ensc|w: yes unaligned access is on by default for armv6+ Dec 14 16:55:26 ensc|w: therefore gcc can convert 4 ldrb into 1 ldr on armv7-a Dec 14 16:56:23 ensc|w: do you have a small example case ? Dec 14 16:59:07 khem: there was a struct bmp_header { ... uint32_t width; ... } __attribute__((__packed__)); the gcc before Dec 2 used 4 lrdb to access width; the new one only one ldr Dec 14 17:03:04 ensc: hmmm ok I think on armv7-a it thinks its no more needed since it can handle unaligned loads Dec 14 17:03:34 btw. its only for gcc-4.6 in meta-oe Dec 14 17:03:57 or-core does not have the unaligned access opts Dec 14 17:08:02 khem: new behavior is ok with me; it appeared just a little bit unexpected and caused problems in a bootloader which worked before Dec 14 17:29:01 what is BBCLASSEXTEND? and when should I use it? Dec 14 17:30:47 khem: hello Dec 14 17:32:55 khem: ping? Dec 14 17:34:56 khem: you have perms to put things on sources.openembedded.org yes? Dec 14 17:47:35 rather off-topic, but how do people debug their init scripts? I used to do enable, disable parts of the scripts to find a bug, but is there a way to echo the execution flow to the console? Dec 14 17:48:44 set -x? Dec 14 17:56:01 Tartarus: yes Dec 14 17:56:35 khem: OK, on further thought I'm just going to fix fakeroot to use the date mechanism to snapshot.debian.org Dec 14 17:56:38 ensc|w: yes I think, I forgot to mention it clearly when Phil asked about the changes when I proposed them Dec 14 17:57:10 Tartarus: I think its best to archive the tars on the mirror Dec 14 17:57:22 so give me a location and we can put the tars ip Dec 14 17:57:24 up Dec 14 17:57:39 We've got two problems 'tho Dec 14 17:57:50 One is that we'll hit the debian not a 404 before we try our mirror Dec 14 17:58:00 Tartarus: we did not use DEBIAN_MIRRORS consistently on oe.dev Dec 14 17:58:11 oh Dec 14 17:58:19 then may be when you are going to fix it Dec 14 17:58:23 then fix it in bb Dec 14 17:58:27 Yeah Dec 14 17:59:38 pb_: tnx Dec 14 18:10:19 re Dec 14 18:36:05 Hi there, I wonder if OE-core supports MACHINE configurations other than "qemuarm" for ARM Dec 14 18:36:49 qemuarm seems to targets armv5 and I'd like to use something more recent Dec 14 18:36:50 oe-core itself only has the qemu machines by design. if you want a bsp for something, add the layer for it Dec 14 18:37:03 e.g. meta-ti has beagleboard, pandaboard, etc Dec 14 18:37:51 kergoth: ok, thanks. Could you suggest a layer that still targets qemu but something more recent (v7 thumb2, neon) Dec 14 18:38:07 you'll have to be more specific than 'arm v7 thumb2' Dec 14 18:38:10 pick a machine Dec 14 18:38:12 I guess the TI layers target real hw Dec 14 18:38:17 yes Dec 14 18:38:47 intentionally we target armv5t as least common denominator Dec 14 18:39:06 I have plans to create meta-qemu-extras Dec 14 18:39:16 where such machines can live Dec 14 18:40:18 sounds good, since qemu can emulate more recent system than verlatilebp nowadays Dec 14 18:40:51 yes it can emulate cortex-a15 supposedly Dec 14 18:41:33 kergoth: wrt "more specific" - I don't really care as long as it boots in qemu : ) Dec 14 18:41:36 there are other qemu arches e.g. sh4 mips64 that might be of interest too Dec 14 18:41:53 I don't know of any layers that add any other qemu machines offhand Dec 14 18:41:54 (should be armv7 thumb2) Dec 14 18:42:03 ok, thanks Dec 14 18:42:28 I'd assume that if qemu supports it, you coulld just modify the qemu machine to use different tunings / .inc files to target something newer without too much difficulty Dec 14 18:43:11 I think there is this base class sanity check that doesn't allow this yet Dec 14 18:43:35 if so, hack it out ;) Dec 14 18:43:45 Is there any documentation on how the mechanisms are for the meta/conf/machine/include/* ? Dec 14 18:44:28 I just noticed them an hour ago and it unclear who pulls these in (oe-core) Dec 14 18:44:42 s/it/it's/ Dec 14 18:44:49 khem: the "Let G++ relocate ..." patch, is that something that should fix the problem I had with having to put the SDK in /usr/local? Dec 14 18:45:19 I tried it out today in case, but it didn't change anything for me Dec 14 18:46:36 kenws: grep is your friend. Dec 14 18:46:46 as you can see in the name of the path, they're included by the machine.. Dec 14 18:47:38 kergoth: yeah but not the armv7 or cortex ones Dec 14 18:47:59 but maybe they are there for other layers to be used as you said earlier Dec 14 18:48:38 just because they aren't included by the machines that are there doesn't, indeed, mean they aren't used by other machines from other layers Dec 14 18:49:10 ok, I see Dec 14 18:57:52 khem: I've got a recipe working that allows me to build the sato and the qt4 demo images using an external csl 2011.03 toolchain. I had to disable localisation though - as it pulls in eglibc-locale no matter what I tried. Is this something worth to post patches onto the mailing list? Dec 14 19:02:02 tasslehoff: no its for relocatability of headers Dec 14 19:02:22 tasslehoff: your problem seems to be relocating gcc itself Dec 14 19:02:32 tasslehoff: I would suggest file a bug in yocto bugzilla Dec 14 19:02:39 so we can track it Dec 14 19:03:02 kenws: it this recipe for external-toolchain ? Dec 14 19:03:22 khem: yes, external-csl-toolchain_arm-2011.03.bb plus inc Dec 14 19:03:26 kenws: I think we need to figure out the reason for locale issue though Dec 14 19:03:32 I did two minor changes to oe-core. One is to be able to overwrite the do_configure_prepend ofeglibc other is a cmake fix Dec 14 19:04:12 it certainly wont hurt to have few eyeballs looking at them so you can send them to oe-core ml Dec 14 19:04:13 khem: locale - yep, I'd appreciate any suggestions on that Dec 14 19:04:43 ok, I'll check for approval internally first and post it asap Dec 14 19:11:44 khem: hm. where do I place this bug? Dec 14 19:12:15 khem: meta recipes -> toolchain? Dec 14 19:13:49 tasslehoff: toolchain Dec 14 20:24:06 khem, just wondering, have there been any TSC meetings recently? Last minutes are from nov 22 afaik Dec 14 20:24:16 and gm ofc Dec 14 20:33:56 eFfeM: yes there was one this week Dec 14 20:34:11 minutes should be out sometime before the week end Dec 14 20:34:24 ah ok, thanks, was just curious Dec 14 20:34:35 there was one which was missed completely due to schedule change Dec 14 20:34:54 its scheduled to be fortnightly Dec 14 20:37:14 eFfeM: how is your uclibc working Dec 14 20:38:01 khem, like a charm! despite being close to release I bit the bullet and went to 2011.3 maintenance and uclibc; Dec 14 20:38:20 had only one problem with net-snmp, moving to a newer version fixed it Dec 14 20:38:39 there was a patch for oe-core after I discovered it, not sure if it has been merged back Dec 14 20:38:45 still too busy to finish off this project Dec 14 20:39:21 cool. I think using 2011.3 maintenance is a wise choice Dec 14 20:39:30 if you are on oe.dev Dec 14 20:39:38 for product pov Dec 14 20:40:05 I just observed that we spin best distros using uclibc out there Dec 14 20:40:58 probably I think uclibc folks have alternative now for a build system Dec 14 20:41:48 moving to oe core was definitely not an option any more inour timeframe Dec 14 20:41:57 I hope to be able to release next week Dec 14 20:42:38 ofc I did not use any gui stuff, I only have our own app, and some helper stuff like busybox, mtd-utils, i2c-tools and net-snmp (and maybe a few more) Dec 14 20:44:05 yes. ok Dec 14 20:44:30 I think if you have next release say in 6months or so I would definitely suggest to use oe-core Dec 14 20:44:42 since now we have tagged a release of oe-core as well Dec 14 20:44:53 * tasslehoff has a release in 3 months, and is very unsure what to do :) Dec 14 20:44:56 and I think there will be another one Dec 14 20:45:21 tasslehoff: weigh in your problems and benefits Dec 14 20:45:34 tasslehoff: I dont know what your pain points are from product POV Dec 14 20:46:23 tasslehoff: I think oe-core has become quite stable now Dec 14 20:46:46 tasslehoff: so I would not write it off from chart as unstable anymore Dec 14 20:47:03 khem: yah. I started the oe-core transition because I suspected we needed better power management than in 2.6.39, but since then we have decided to skip some fancy suspendstuff in the first release Dec 14 20:47:40 we've been running on the latest rootfs I created from oe-classic for some months now, almost without problems. Dec 14 20:47:46 oe-core is lot more predictable in its builds then oe.dev Dec 14 20:48:04 tasslehoff: cool. Dec 14 20:48:15 tasslehoff: are you on the 2011.03 branch ? Dec 14 20:48:47 khem: nope, on dev Dec 14 20:50:54 hrmmm Dec 14 20:52:20 khem: the only things not working for me now are systemd-related. will have to try and figure those out tomorrow (or base my work on a core image using sysvinit). Dec 14 20:52:43 khem: think I should've been on 2011.03? Dec 14 20:53:24 yes if you are releasing on oe.dev codebase then 2011.03 maintenance branch is better option Dec 14 20:53:27 since its maintained Dec 14 20:53:36 you will get bug fixes Dec 14 20:54:27 khem: that is useful information. thanks :) Dec 14 21:12:11 khem: any idea how long it will be maintained? Dec 14 23:50:02 a ${DATETIME} PV is upgrade safe, right? Dec 14 23:54:06 Jin^eLD: thats the buildtime stamp Dec 14 23:54:14 Jin^eLD: why do u want to use it ? Dec 14 23:54:42 khem: I want to hack the angstrom version so it always get rebuilt when I generate an image Dec 14 23:55:05 ok Dec 14 23:55:30 was just looking for a mechanism that would auto rebuild it each time, time stamp seems suitable.. Dec 14 23:55:41 it should be upgradable too Dec 14 23:56:16 as long as its UTC Dec 14 23:56:23 or say one timezone Dec 14 23:56:34 oh indeed Dec 14 23:56:45 but well we'll be using one build machine only for the feeds Dec 14 23:56:51 so I guess that should be ok Dec 14 23:57:06 k Dec 15 00:27:49 nite everyone **** ENDING LOGGING AT Thu Dec 15 02:59:57 2011