**** BEGIN LOGGING AT Tue Dec 21 02:59:59 2010 Dec 21 06:34:24 03Khem Raj  07master * r06aca2f101 10openembedded.git/recipes/uclibc/uclibc.inc: Dec 21 06:34:24 uclibc.inc: Provide libsegfault 'fakely' Dec 21 06:34:24 Signed-off-by: Khem Raj Dec 21 06:34:38 03Naresh Medisetty  07master * r14e4ab4a55 10openembedded.git/recipes/ti/ (ti-lftb.inc ti-lftb_2.0.bb): (log message trimmed) Dec 21 06:34:38 lftb: add ti LFTB recipe Dec 21 06:34:38 * This package contains functional test suites for TI devices Dec 21 06:34:38 used to verify the Linux kernel and drivers for the various Dec 21 06:34:38 peripherals found on TI devices. Dec 21 06:34:38 Signed-off-by: Naresh Medisetty Dec 21 06:34:38 Signed-off-by: Chase Maupin Dec 21 07:00:18 What package is responsible for renaming: syslog.busybox and syslog.syslog-ng Dec 21 07:02:17 can someone with write privs on the wiki please test that it works to write? Dec 21 07:11:27 ka6sox: seems to be working Dec 21 07:13:22 ello folks Dec 21 07:13:48 khem, thanks Dec 21 07:22:54 davidlt: busybox recipe will install syslog.busybox and then use update-alternatives to make it syslog Dec 21 07:24:04 khem: that's the problem, it didn't Dec 21 07:24:11 davidlt: similarily rsyslog or syslog-ng will install them too Dec 21 07:24:27 But looks like clean & build solved problem Dec 21 07:24:35 hmm Dec 21 07:24:50 zecke: guten morgen Dec 21 07:25:15 * davidlt run to his train Dec 21 07:45:09 Please forgive me for asking, I am a little bit confused to what is going on. What is the yocto impact on the TI-based development boards? And following the same trail, what is the relation between yocto and arago? Dec 21 07:45:44 Ill ask the last thingy again on #arago Dec 21 07:48:07 Gaston|Home: probably folks on #arago can answer you better Dec 21 07:48:41 Gaston|Home: however yocto is OpenEmbedded Architecture so it should have minimal impact Dec 21 07:49:31 openembedded is going to use a concept of layers which means OE and yocto will complement earch other Dec 21 07:50:41 It is relatively confusing for me, to start with where will yocto pull from? Dec 21 07:51:13 yocto has its own repository like arago has Dec 21 07:51:28 I assume that OE will source all core development tools from yocto, right? Dec 21 07:52:18 But it is clearly outspoken that yocto will be pull-based repository Dec 21 07:52:40 Gaston|Home: thats long term goal when all needed features of OE and yocto merge Dec 21 07:53:11 Gaston|Home: yes it does not matter if its pull or push Dec 21 07:53:28 pull works better if you have people doing integration full time 24/7 Dec 21 07:53:37 which yocto has Dec 21 07:53:52 frankly I would prefer something similar in OE Dec 21 07:54:07 and would be more possible when we split out into layers Dec 21 07:54:43 best is to allow various contrib branches where devs can push there branches for pull into master Dec 21 07:55:30 yes, that sound reasonable Dec 21 07:56:29 Gaston|Home: but in OE devs have limited time as there are hardly paid developers to just work on OE upstream Dec 21 07:56:39 so we share the burden with push model Dec 21 07:57:29 thats a bit messy because push model can easily step on earch others toes Dec 21 07:57:42 Gaston|Home: what do u use today wrt OE Dec 21 07:57:52 khem, ok, I feel like youve tried to answer my questions, but somehow I'm still confused. I guess things will pan out as we go along... Dec 21 07:58:26 khem, I build images for use with Hawkboard Dec 21 07:58:40 Gaston|Home: to a certain extent yes but dont worry too much I would say Dec 21 07:59:26 Gaston|Home: OK so in your case in future OE you would create a BSP layer for hawkboard Dec 21 07:59:33 and probably maintain that Dec 21 07:59:53 and it will be hosted on OE repo Dec 21 07:59:57 * JaMa|Off also fears a bit that all those layers and amends will make OE a bit more difficult to use (keeping eye on all changes in different layer and checking if all amends apply where and as they should) Dec 21 08:00:36 yes there are certain things that can not be said firm atm Dec 21 08:00:43 we need to experiment with layers Dec 21 08:00:48 and polish them as we go Dec 21 08:01:10 I think my main concern is that TI/arago will lag even more. I was kind of putting hopes on that arago would be more closely tracking OE. I wonder if this will drive it in a positive or negative way? Dec 21 08:01:46 Some statements have been made that arago would completely merge in to OE Dec 21 08:02:04 I wonder if that is still viable Dec 21 08:02:10 Gaston|Home: if arago is maintained in OE like SHR or angstrom then it would be best Dec 21 08:02:54 I agree Dec 21 08:02:55 but thats arago's decision point I have no say in that Dec 21 08:03:41 JaMa|Off: wrt layers we all are inexperienced atm Dec 21 08:03:41 khem: ping Dec 21 08:03:54 davidlt: how was the train ride Dec 21 08:04:17 khem: I wasn't late this time :) Dec 21 08:05:10 good Dec 21 08:05:14 Q: what is the best way to do u-boot environment modification? (Right now I change environment after flashing NAND, but I wanna put that into bitbake building) Dec 21 08:06:36 I have it as patch in recipe Dec 21 08:07:01 JaMa|Off: more details? Dec 21 08:07:04 davidlt: yeah like JaMa|Off said make a machine specific patch Dec 21 08:07:12 khem, depending all on headers papers over a missing dependency Dec 21 08:07:26 blindvt`: which one ? Dec 21 08:07:26 but problem is that ie on n900 there is no preferred layout for nand/uSD.. so I'll make that patch not only machine specific but also for SHR only Dec 21 08:07:38 All patches which affect my machine looks like are locatedin here: recipes/u-boot/u-boot-git/beagleboard Dec 21 08:07:53 blindvt`: and I think all should be doing headers anyway Dec 21 08:08:03 if we are to build out of src tree Dec 21 08:08:47 davidlt: http://gitorious.org/~jama/angstrom/jama-shr-experimental/commit/e35cf21d565639e56ba99a556653ce2043ad2cb7 patches 0008+ Dec 21 08:08:56 khem, somewhere a dep on uClibc_ctype.h must be missing or something Dec 21 08:08:58 davidlt: yes thats ok location Dec 21 08:09:14 blindvt`: yes I have added that too Dec 21 08:09:26 see one of my recent commits Dec 21 08:10:22 blindvt`: I will sync nptl once .32 is out of door Dec 21 08:10:23 khem, i've seen that, yes. Still, headers should not be a prereq of all; There should be a discussion with psm and me about that in rikers logs Dec 21 08:10:31 khem, cool! Dec 21 08:10:43 ~seen kergoth Dec 21 08:10:44 kergoth <~kergoth@ip24-251-170-95.ph.ph.cox.net> was last seen on IRC in channel #oe, 11h 59m 37s ago, saying: 'np'. Dec 21 08:11:20 blindvt`: hmm ok so u think headers target is only external and should not be part of all Dec 21 08:11:39 which is a fair argument Dec 21 08:12:53 blindvt: there is a lot of things that depend on headers location as of today Dec 21 08:13:10 so if you dont create those symlinks then things go wrong Dec 21 08:13:29 somehow build system expects headers to be staged that way Dec 21 08:14:15 so I think in grand scheme of things its not bad to have then staged for build you may remove headers-install out of 'all' Dec 21 08:14:33 good morning Dec 21 08:14:33 kergoth, I manage to end up with revdep not in explored_deps and this leads to a key error in find_chains thus preventing us to print the dep-loops we found. I'm unsure how to correctly deal with this situation though: http://paste.debian.net/102895/ allows for printing out the dep-loops but is perhaps not the correct thing to do Dec 21 08:14:51 probably headers = headers_compile headers-install Dec 21 08:15:32 and we could use headers-compile target in all Dec 21 08:21:11 kergoth, full 4.6MB log with this non-patch above applied: http://uclibc.org/~aldot/bitbake/nohup.out-rq-find_chains-keyerror Dec 21 08:21:39 kergoth, not too pretty but alot more informative than not printing out the loops at all Dec 21 08:26:32 hmm anyone knows if theres a way to tell oe not to build the kernel? Dec 21 08:26:37 I'm building it by hand Dec 21 08:27:42 atiti: the kernel may be needed by some library you are building with OE Dec 21 08:28:39 atiti: you could build it once as reference for next OE builds Dec 21 08:35:06 atiti: basically virtual/kernel is set to something Dec 21 08:35:33 you can try to set it to something else and see if you can fool bb Dec 21 08:36:29 something else like "" ? Dec 21 08:36:44 quick question about PSTAGE_BUILD_CMD: +# FIXME: redundancy WRT bitbake.conf's PKGBUILDCMD ? Dec 21 08:38:33 not sure but perhaps set it to assume provided Dec 21 08:50:23 Hi Dec 21 08:50:53 Is there any application in oe for CAN Dec 21 09:24:02 khem: hi Dec 21 09:48:07 hi Dec 21 09:48:19 nani_: you have socketcan and canutils Dec 21 10:40:14 Hi, I'm trying to add 'xmlpull' to my image task file but bitbake complains it doesn't exist Dec 21 10:40:28 In the meanwhile, 'bitbake xmlpull' works as it's supposed to Dec 21 10:40:38 did you look at the recipe? Dec 21 10:40:45 maybee the ipk name differs Dec 21 10:41:08 libxmlpull is the name of the resulting package Dec 21 10:41:11 Which doesn't work either Dec 21 10:41:41 Ah Dec 21 10:41:46 I may have that wrong Dec 21 10:41:50 libxmlpull-java Dec 21 10:42:40 Sorry, it works now, thank you. Dec 21 10:42:47 no prob Dec 21 10:58:19 03Koen Kooi  07org.openembedded.dev * rcfbd56bf57 10openembedded.git/recipes/gstreamer/ (gst-rtsp.inc gst-rtsp_0.10.7.bb): Dec 21 10:58:19 gst-rtsp: fix gettext issues Dec 21 10:58:19 Signed-off-by: Koen Kooi Dec 21 11:03:15 03Koen Kooi  07org.openembedded.dev * r7723400e2b 10openembedded.git/recipes/gstreamer/gst-rtsp.inc: Dec 21 11:03:15 gst-rtsp: fix typo Dec 21 11:03:15 trying to type over changes from another buildhost doesn't work too well Dec 21 11:22:30 03Koen Kooi  07org.openembedded.dev * r2ce320cafa 10openembedded.git/recipes/dvbtools/ (3 files in 2 dirs): Dec 21 11:22:30 dvb-apps: update to current hg tip to fix build issues with recent gcc versions Dec 21 11:22:30 Signed-off-by: Koen Kooi Dec 21 11:32:21 ugh. can i inherit conditionally? Dec 21 11:33:03 i don't want base.bbclass to unconditionally inherit patch, only if a recipe actually references a patch! Dec 21 11:38:48 blindvt`: if patch.bbclass is doing something you don't want then surely it would be best to fix the class itself? Dec 21 12:09:40 03Koen Kooi  07org.openembedded.dev * rf1970eaba5 10openembedded.git/recipes/dvbtools/wscan_20101204.bb: Dec 21 12:09:40 wscan: add 20101204 version Dec 21 12:09:40 * this one adds a few extra symbol rates to scan for Dec 21 12:09:40 Signed-off-by: Koen Kooi Dec 21 12:09:50 03Koen Kooi  07org.openembedded.dev * ra8f03d20e5 10openembedded.git/conf/distro/include/angstrom-2010-preferred-versions.inc: Dec 21 12:09:50 angstrom next: switch to udev 165 Dec 21 12:09:50 Signed-off-by: Koen Kooi Dec 21 12:09:52 03Koen Kooi  07org.openembedded.dev * r4ec8b82808 10openembedded.git/recipes/udev/ (19 files in 9 dirs): Dec 21 12:09:52 udev: add 165 Dec 21 12:09:52 Signed-off-by: Koen Kooi Dec 21 12:21:21 03Koen Kooi  07org.openembedded.dev * rafb05a23b2 10openembedded.git/ (2 files in 2 dirs): Dec 21 12:21:21 linux-omap4: enable some more modules Dec 21 12:21:21 Signed-off-by: Koen Kooi Dec 21 12:46:53 bluelightning, sounds like a .plan, yes :) http://paste.debian.net/102915/ Dec 21 13:34:51 hmm Dec 21 13:34:52 gnu-configize: command not found Dec 21 14:58:16 hi kergoth Dec 21 15:08:02 hi khem : for asterisk, do you prefer I move the recipes to non working ? Dec 21 15:08:48 I'm trying to fix fetching issues for bitbake world Dec 21 15:11:10 ericben: then please use SOURCE_MIRROR_FETCH to fetch sources also for incompatible recipes with COMPATIBLE_HOST|COMPATIBLE_MACHINE etc Dec 21 15:12:18 JaMa|Off: what do you mean ? Dec 21 15:13:30 JaMa|Off: ok I found it in conf/documentation.conf Dec 21 15:14:00 JaMa|Off: thanks for the hint Dec 21 15:14:19 ericben: yes move to nonworking Dec 21 15:14:22 ericben: it won't solve all issues you reported in "[oe] Problem with bitbake master & OE master during fetch" but will allow you to check more SRC_URIs Dec 21 15:14:34 that way if someone needs them he/she can do whatever Dec 21 15:14:41 woglinde, I got jamvm + midpath working, I'll post patches later. Dec 21 15:14:54 B_Lizzard good Dec 21 15:15:00 You mentioned that jamvm + midpath would work better than phoneme? Dec 21 15:15:13 I thought phoneme was the reference implementation Dec 21 15:15:44 khem: ok will do. btw I'm actually testing your latest toolchain upgrade, I hope to have armv5, v6, v4 compiled by tomorrow. Dec 21 15:15:51 Unless it needs a GTK AWT or something like that Dec 21 15:15:56 03Richard Purdie  07master * r9175024d1a 10bitbake.git/lib/bb/runqueue.py: Dec 21 15:15:56 bitbake/runqueue.py: Ensure rqexe always exists and that empty task lists cause a graceful exit Dec 21 15:15:56 Signed-off-by: Richard Purdie Dec 21 15:15:56 Signed-off-by: Chris Larson Dec 21 15:16:00 ericben: great Dec 21 15:17:02 * JaMa|Off also have latest gcc patch compiled.. but probably won't be enough for u-boot fix Dec 21 15:20:09 03Gabbasov, Andrew  07org.openembedded.dev * r9045fa6ab7 10openembedded.git/recipes/lttng/ust.inc: (log message trimmed) Dec 21 15:20:09 ust.inc: Rework FILES Dec 21 15:20:09 libust.so is actually an ld script (grouping libust.so.0 and Dec 21 15:20:09 libust_initializer.o), so I doubt it has any usefullness on the target. The Dec 21 15:20:09 note about preloading should concern other libust*.so, that are indeed used in Dec 21 15:20:10 preloading by 'usttrace' script. And these .so libraries are going to target, Dec 21 15:20:11 not to -dev. And for libust.so that script preloads libust.so.0. Dec 21 15:24:38 JaMa|Off: this u-boot niggle needs to be debugged Dec 21 15:24:53 did u manage to get it on uboot.git too Dec 21 15:25:20 u-boot for arm is actually difficult to debug because of the new relocation code which broke lot of platforms Dec 21 15:40:28 ericben: so it copies itself elsewhere into ram you mean Dec 21 15:40:43 no more execute from flash kind of thing Dec 21 15:41:12 khem: it was already copying itself in ram before Dec 21 15:42:34 khem: I've not followed exactly the recent changes but the way relocation is done has changed for arm and is more generic than it was before from what I understood Dec 21 15:51:39 khem: I have it in u-boot_git.bb but with older SRCREV and as ericben said relocation changes needs more attention than I had time for, too busy with daywork lately :/ Dec 21 15:53:40 ericben: there is nice readme in u-boot tree doc/README.arm-relocation, but even after reading this and updating n900 patches I got only NOLO bootloader hanging before starting u-boot (and without any output/serial port) Dec 21 15:55:38 JaMa|Off: I won't be of big help here as I still have to find time to update the boards I maintain in u-boot ... Dec 21 15:56:39 so I have tried latest SRCREV before relocation stuff was merged and I have running u-boot again, but hanging while starting kernel (like old u-boot did when built with gcc-4.5, but this time also with old gcc) Dec 21 16:45:21 03Koen Kooi  07org.openembedded.dev * r3c0711605b 10openembedded.git/recipes/linux/ (9 files in 2 dirs): Dec 21 16:45:21 linux-omap4: readd some missing patches Dec 21 16:45:21 Signed-off-by: Koen Kooi Dec 21 16:45:23 03Koen Kooi  07org.openembedded.dev * r0d06f4915d 10openembedded.git/recipes/ti/libdce_git.bb: Dec 21 16:45:23 libdce: roll back SRCREV again to make omapfbplay work Dec 21 16:45:23 Signed-off-by: Koen Kooi Dec 21 16:49:21 JaMa|Off: which uboot recipe should I try Dec 21 16:49:32 JaMa|Off: I will try to debug u-boot with qemu Dec 21 16:49:41 * khem has done that before Dec 21 17:01:58 hi ph5 Dec 21 17:02:07 hi woglinde Dec 21 17:02:37 hm do we have selinux support in oe? Dec 21 17:03:45 damn coreutils Dec 21 17:03:51 all I wand is a static mknod Dec 21 17:19:41 khem: here is my u-boot_git.bb patch http://gitorious.org/~jama/angstrom/jama-shr-experimental/commit/e35cf21d565639e56ba99a556653ce2043ad2cb7, but maybe that problem reveals itself only on n900.. Dec 21 17:20:22 re zecke Dec 21 17:27:47 khem: just in case you found them usefull I'm uploading u-boot workdirs to http://build.shr-project.org/tests/jama/u-boot/ tmpdir-u-boot-ang-binutils-2.20.1-gcc-4.4.4.tar.bz2 is last working version, then there will be tmpdir-u-boot-shr which is toolchain corresponding to week old sane-toolchain and then gcc-4.5v.tar.bz2 and gcc-4.5vv.tar.bz2 are from gcc-4.5 without linaro patches and without almost all patches Dec 21 17:28:58 khem: I'll test binary built with current gcc + your patches sent yesterday in an hour or so (leaving work now) Dec 21 17:31:34 JaMa|Off: ok Dec 21 18:33:37 hi all Dec 21 18:34:32 reactor16: hello Dec 21 18:36:16 obi are you here ? Dec 21 18:37:32 yes Dec 21 18:37:41 hi man Dec 21 18:37:51 what's up bro Dec 21 18:39:27 obi: pm please Dec 21 18:47:30 mickey do you have any plans on how to handle minimal in relation to yocto? I saw koen seems to work toward turning angstrom into a layer Dec 21 18:50:49 hello all Dec 21 18:51:04 if I have two machines (palmpre and palmpre2) Dec 21 18:51:19 and I want palmpre2 to use palmpre overrides too Dec 21 18:51:30 03Koen Kooi  07org.openembedded.dev * r6ae45bbf2b 10openembedded.git/classes/package_ipk.bbclass: (log message trimmed) Dec 21 18:51:30 package ipk bbclass: store build branch and revision in ipkg metadata Dec 21 18:51:30 The ipkg metadata will look like this now: Dec 21 18:51:30 koen@dominion:/OE/angstrom-dev/deploy/glibc$ dpkg-deb -I ipk/am3517-evm/matrix-gui_1.3-r19.0.6_am3517-evm.ipk Dec 21 18:51:30 new debian package, version 2.0. Dec 21 18:51:30 size 24112 bytes: control archive= 540 bytes. Dec 21 18:51:31 629 bytes, 13 lines control Dec 21 18:51:33 MACHINE_OVERRIDES += "palmpre palmpre2" ? Dec 21 18:52:00 as then we could split up palmpre and palmpre2 into two config files an a palmpre.inc with the basic settings Dec 21 18:53:53 mrmoku: look at http://docs.openembedded.org/usermanual/usermanual.html chapter "Adding a new Machine" Dec 21 18:53:57 it should be the right option Dec 21 18:54:25 but whats with MACHINE_CLASS? Dec 21 18:56:09 morphis: written there some paragraph down Dec 21 18:56:23 MACHINE_CLASS might be used to describe a class of devices such as a cell phone in which the processor may be different but the features such as touchscreen, GPS, modem, etc are the same Dec 21 18:59:42 thats the case for palmpre and palmpre2 Dec 21 18:59:49 just a different processor Dec 21 19:00:26 but if I only declare the same MACHINE_CLASS for both would the overrides still work? Dec 21 19:00:52 a palmpre.inc with MACHINE_CLASS="palmpre" which is included by palmpre.conf and palmpre2.conf Dec 21 19:01:12 grepping for MACHINE_CLASS reveals there is 'bigscreen' and 'smallscreen' in use Dec 21 19:01:22 thats GUI_MACHINE_CLASS :) Dec 21 19:01:43 htc-msm7 and htc-qsd8 are values for MACHINE_CLASS Dec 21 19:01:47 duh Dec 21 19:01:50 * mrmoku puts on his glasses Dec 21 19:02:04 :) Dec 21 19:03:09 looks like MACHINE_CLASS is the correct thing Dec 21 19:03:27 when you look at motorola-ezx-base.inc Dec 21 19:03:30 eFfeM: i'm not convinced yet that a distro deserves a seperate layer, but if the general opinion is that, then I'd follow suit Dec 21 19:03:35 yes, MACHINE_CLASS is it Dec 21 19:03:44 iirc it's even by default in OVERRIDES if you're using minimal Dec 21 19:03:44 :) Dec 21 19:03:55 I am using SHR Dec 21 19:04:12 but I hope its the same for SHR Dec 21 19:04:19 if not, we can make it so... Dec 21 19:05:39 ok Dec 21 19:05:52 but then I can work with palmpre and palmpre2 overrides? Dec 21 19:06:04 or is then only palmpre a valid one? Dec 21 19:06:48 mickeyl: I think that distros should have option to have own layers Dec 21 19:07:33 some will use them, some not Dec 21 19:08:51 same with bsp - mckoan will like to have bsp/ronetix and maybe bsp/at91 for his boards Dec 21 19:11:23 morphis: yeah, we have MACHINE_CLASS in overrides Dec 21 19:11:39 great Dec 21 19:13:47 ep93xx boards can have toolchain addons in their bsp/ep93xx layer for example... Dec 21 19:14:16 * hrw out Dec 21 19:20:20 hrw: *nod* Dec 21 19:56:38 man git test-sequence is handy Dec 21 20:04:01 mickeyl: what makes things fuzzy for me is where image and takss recipes will live, i saw koen has put console-image in the angstrom layer Dec 21 20:04:37 kergoth_: https://github.com/foerster/bitbake/commit/80e3d3a130b9dee72c11c6946bb5ff7705111d7c Dec 21 20:05:12 foerster: saw it in the fork queue earlier, looks good to me Dec 21 20:05:27 someone was using depexp last night and complained :) Dec 21 20:05:30 hehe Dec 21 20:05:33 so I figured out how to make it work the right way Dec 21 20:05:37 * kergoth_ 's never really used it, to be honest Dec 21 20:05:50 well, other than to go 'nifty, *close*' Dec 21 20:05:52 me either, other than firing it up and going "ooh, neat" Dec 21 20:05:53 :) Dec 21 20:05:55 hehe Dec 21 20:08:06 damnit, undocumented binary protocols are a pain in my ass Dec 21 20:09:53 re Dec 21 20:10:03 re hrw Dec 21 20:10:08 eFfeM: console-image was angstrom image first Dec 21 20:10:33 eFfeM: I think that OE will need few more layers Dec 21 20:11:27 hrw, i know console-image was angstrom first, we need to think about a generic solution Dec 21 20:12:06 yocto-core (from yocto git), oe-core (addon to yocto with core stuff (images, classes), oe-distro-DISTRO (for those distros which needs own layers - like angstrom does), oe-bsp-SOMETHING (SOMETHING can be vendor/machine/soc) Dec 21 20:12:33 yocto-core is on yocto git server, git pull only way of providing changes - like poky does now Dec 21 20:13:00 that seems a good plan to me, what I like less is currently people already start implemting things before there is agreement and before consequences are clar Dec 21 20:13:06 oe-core on OE server - same policy as yocto-core (pull updates from user branches only if they do not break oe-core) Dec 21 20:13:31 oe-distro-DISTRO maintained by distro maintainers with their policies Dec 21 20:13:47 oe-bsp-STH maintained by layer maintainers with their policies Dec 21 20:14:16 who will maintain oe-core ? Dec 21 20:14:19 oe-extra-STH (STH = opie, xfce, whatever) maintained by person/team Dec 21 20:14:31 btw still seems a good plan to me Dec 21 20:14:34 eFfeM: to be discussed Dec 21 20:14:55 and oe-unmaintained layer with everything not fit in layers Dec 21 20:15:45 hrw, seems a fine plan to me, suggest that you toss this on the list Dec 21 20:16:22 I am looking where to hook with it Dec 21 20:16:24 but i must say that I was kinda surprised by the sudden creation of meta-openembedded, before discussing this within the community Dec 21 20:17:07 eFfeM: I think that Koen did good job with it Dec 21 20:17:17 agreed Dec 21 20:17:45 ok, me -> mailer Dec 21 20:18:19 nobody said it's final solution, but it looks like good start (as we need something to discuss about first) Dec 21 20:18:33 i think the stuff he did on gitorious was good (and I also acknowledged that on irc) but taking it over on oe git was way too quickly. I felt it a good starting point ti direct the discussion Dec 21 20:20:18 oops Dec 21 20:20:47 eFfeM: he could push to koen/meta-openembedded on OE git server too Dec 21 20:20:47 might have missed hte last msg or 2 as I accidently clicked X when toggling widnows Dec 21 20:21:06 hrw, i think that would have been much better Dec 21 20:21:35 this makes it more official than it IMHO is Dec 21 20:30:16 sent Dec 21 20:32:03 thanks Dec 21 20:35:41 hm, not sure what is happening here, but if I start a bake it parses, prints the build config and then seems to hang Dec 21 20:36:16 weird, I jsut saw that a little while ago Dec 21 20:36:22 after a while it started Dec 21 20:36:34 i'll wait a little Dec 21 20:36:36 tinderbox maybe? Dec 21 20:36:43 the odd thing is that there is no activity Dec 21 20:36:48 ah could be Dec 21 20:36:54 hello Dec 21 20:36:57 obviously the server we upload our personal information too is down! Dec 21 20:37:35 is here the right place for posting questions? Dec 21 20:37:44 go ahead Dec 21 20:37:47 Crofton ah ok Dec 21 20:37:55 if we do not like the question, we will say so :) Dec 21 20:39:27 iam trying to get additional wifi drivers for my oe system, now i am trying to build them on the embedded system, but there are no linux headers i need. Question: can i build drivers with bitcake / oe? Dec 21 20:39:53 jano23, you should be able to Dec 21 20:41:02 i allready red so much stuff... where could i get the instructions? Dec 21 20:42:12 find a similar recipe and start there Dec 21 20:42:29 @Crofton|work: thanks for the answer, do you have a hint i could catch up? Dec 21 20:43:55 I'm not familiar with wifi drivers, so I can't make a good guess for you Dec 21 20:45:23 thanks so far, i will go for example recipes, lets see how far i will get :-) Dec 21 20:46:16 jano23: which drivers you need? Dec 21 20:47:41 @hrw i need drivers for the wl062 (zioncom) Dec 21 20:48:15 got the wifi usb stick working with the combat wireless drivers Dec 21 20:48:19 jano23: and they are only available out of kernel - right? Dec 21 20:48:32 ah. compat-wireless works? good thing Dec 21 20:48:42 jano23: no way to upgrade device kernel? Dec 21 20:49:08 yes, i got them working on my ubuntu workstation because i have the linux-headers on that machine Dec 21 20:49:31 btw, how can i send direkt messages? :-) Dec 21 20:49:43 jano23: I do not accept private messages on irc Dec 21 20:50:14 on my embedded system i dont have the needed headers Dec 21 20:50:21 jano23: OE target devices do not get linux-headers. We prefer to do builds by using OE then by using target devices Dec 21 20:50:43 though we really should generate kernel source/header packages at some point Dec 21 20:51:06 when i try to build the drivers on the embedded system, i get the following err: make: *** /lib/modules/2.6.34/build: No such file or directory. Stop. Dec 21 20:51:08 kergoth_: agreed Dec 21 20:51:41 jano23: short answer: stop that. Dec 21 20:51:45 jano23: take a look at fuse/fuse-module_2.7.4.bb recipe. it is old but shows how to build external modules in OE Dec 21 20:51:56 as hrw just explained, we don't generally build kernel modules on the device Dec 21 20:52:56 to learn how to build modules external would be fine, i will take a look for fuse, thank you so far Dec 21 20:57:04 cbrake: the web gui of git (http://cgit.openembedded.org/cgit.cgi/openembedded/) seems to requilre some love after the move, its log history says the last commit is 9 days ago) Dec 21 20:58:35 eFfeM: odd Dec 21 21:02:19 also doesn't show master/org.openembedded.dev now afais Dec 21 21:03:22 yeah, seems like cgit can't see the master Dec 21 21:03:32 its config is fairly simple in that it just points directly at the repo Dec 21 21:03:58 seems like the repo is still ok, so must be a cgit bug Dec 21 21:04:26 yup just pushed few patches ok Dec 21 21:04:37 did the IRC notifications show up? Dec 21 21:04:43 only CIA didn't notice those Dec 21 21:05:30 so no Dec 21 21:09:50 appears to be a permission problem Dec 21 21:10:03 manually add a+r fixed it Dec 21 21:10:07 (cgit) Dec 21 21:10:34 great thank you Dec 21 21:11:07 btw is tinderbox.openembedded.net running? Dec 21 21:11:41 I had to disable oestat-client yesterday, because it wasn't and seems still isn't from here Dec 21 21:12:11 pretty sure tinderbox is unresponisive, based on my oe run earlier and eFfeM's observation Dec 21 21:13:33 i turned oestats-client or whatever the name is off, and things became a lot faster Dec 21 21:14:33 do you know the point where u read and read and just dont get the clue.... basic question concerning building modules w/ bitbake: how to start at all? i have a driver folder with makefile, *.c files an i have the fuse-module recipe... Dec 21 21:17:22 ah tinderbox does respond, but it's really very slow Dec 21 21:22:05 btw is this known? I have libtool issues with fontconfig. I am at git head, but I did move from opensuse 11.2 to 11.3 last saturday Dec 21 21:22:21 libtool 2.4 Dec 21 21:24:53 fontconfig compiles fine here Dec 21 21:30:33 03Cliff Brake  07master * r9bec8e2f1c 10openembedded.git/README: README: dummy commit to test Dec 21 21:32:08 03Cliff Brake  07master * r46c561bae1 10openembedded.git/README: README: another test commit Dec 21 21:32:22 ok, I think CIA is back :-) Dec 21 21:32:28 hehe Dec 21 21:33:15 * kergoth_ hugs CIA-1 Dec 21 21:33:15 * CIA-1 hugs kergoth_ Dec 21 21:33:26 jama Dec 21 21:33:27 TLSXDE Dec 21 21:33:29 oops Dec 21 21:33:38 | /usr/bin/grep: /usr/lib/libz.la: No such file or directory Dec 21 21:33:39 | /usr/bin/sed: can't read /usr/lib/libz.la: No such file or directory Dec 21 21:33:39 | arm-oe-linux-gnueabi-libtool: link: `/usr/lib/libz.la' is not a valid libtool archive Dec 21 21:34:01 pastebin libz.la Dec 21 21:34:17 do you have /usr/lib/libz.la ? Dec 21 21:34:29 he means from sysroot-target Dec 21 21:34:41 yes from sysroot Dec 21 21:35:04 yes, understood searching it Dec 21 21:35:47 here is mine http://paste.pocoo.org/show/308094/ Dec 21 21:36:04 http://www.pastebin.ca/2025708 Dec 21 21:36:49 looks good, can you check which .la depends on it? Dec 21 21:37:10 the differnece is that I have installed=no and you have installed=yes Dec 21 21:37:44 oops and the dependency libs path Dec 21 21:38:08 try to grep /usr/lib/libz.la | grep -v =/usr/lib/libz.la Dec 21 21:38:25 ahh yours libz.la doesn't look like from libtool with sysroot enabled Dec 21 21:39:05 did you rebuild zlib after that last sane-toolchain.inc fix? Dec 21 21:39:10 ah ok, i thought I generated it after I enabled sysroot Dec 21 21:39:10 jama how the libz.la should look like? Dec 21 21:39:14 will rebuild Dec 21 21:39:24 woglinde: see my paste Dec 21 21:39:26 woglinde: like the one JaMa showed' Dec 21 21:39:55 hm Dec 21 21:40:14 woglinde: and in more complex example you should see '=' instead "/home/frans/oe/tmp_minimal/sysroots/armv7a-oe-linux-gnueabi/" Dec 21 21:41:02 woglinde: for example libfontconfig.la http://paste.pocoo.org/show/308102/ Dec 21 21:41:46 guess this means a clean rebuilt for me, Dec 21 21:42:05 woglinde: and that grep+sed from eFfeM error output are trying to replace '=' with actuall sysroot val passed as parameter Dec 21 21:42:28 eFfeM: yes, clean rebuild is needed to "fix" all .la files Dec 21 21:42:35 jama hm anyidea how I can fix the openjdk build? Dec 21 21:42:42 will try fontconfig first Dec 21 21:43:09 I need to call our autotools.bbclass stuff by hand from a Makefile Dec 21 21:43:15 for configure Dec 21 21:43:36 I call it too ie in python iirc (for ctypes) Dec 21 21:44:04 do_configure_prepend() { autoreconf -Wcross --verbose --install --force --exclude=autopoint Modules/_ctypes/libffi || oenote "_ctypes failed to autoreconf" Dec 21 21:44:43 so probably something similar could be used in openjdk? Dec 21 21:45:33 hm I tried but the libtool script generated still replaces -lz with /usr/lib/libz.so Dec 21 21:45:43 maybee I will try again Dec 21 21:46:10 does it generate right libtool script? Dec 21 21:46:24 isn't it older version from m4/*? Dec 21 21:46:42 nono I took care that m4 got ereased Dec 21 21:47:01 * JaMa -> sleep() Dec 21 21:47:07 woglinde: ah :/ Dec 21 21:48:32 jama thanks anyway Dec 21 21:53:32 seems the libz issue is now ok, trying fontconfig as a test Dec 21 21:53:52 but now seem to get this Dec 21 21:53:53 Traceback (most recent call last): Dec 21 21:53:53 File "/usr/lib/python2.6/multiprocessing/queues.py", line 233, in _feed Dec 21 21:53:53 debug('feeder thread got sentinel -- exiting') Dec 21 21:53:53 TypeError: 'NoneType' object is not callable Dec 21 21:54:03 bitbake git head this happens after rm_work Dec 21 21:56:00 doesn't happen after rm_work here, i always use rm_work Dec 21 21:56:46 kergoth_: happens here after rm_work too Dec 21 21:57:33 JaMa|Off: I did clean and rebuild zlib, my libz.la looks exactly like yours, still fontconfig fails with the same error (I did do a -cclean of fontconfig too) Dec 21 21:57:36 you just said that Dec 21 21:57:39 i heard you the first tiem Dec 21 21:57:44 14:52 < eFfeM> bitbake git head this happens after rm_work Dec 21 21:58:08 kergoth_: ah yes, misunderstood your remark Dec 21 21:58:40 kergoth_: the issue is it is a python error in queues.py Dec 21 21:59:02 yes, i know, i read the error message you pasted 5 minutes ago Dec 21 21:59:10 i'm not sure why you seem to think i can't read Dec 21 21:59:20 but i'll keep an eye open for it Dec 21 21:59:44 ah ok, well actually my brain is not really in gear yet, recovering from flu Dec 21 21:59:58 funny, I had a bug yesterday Dec 21 22:02:27 kergoth_: I'll see if I can reproduce it; i've thrown away the cache, the only odd thing I can think of is that I did a -cclean with a wrong pacakge name Dec 21 22:02:39 k Dec 21 22:02:56 cbrake: thanks for fixing cia and cgit Dec 21 22:03:16 i'm sure there are bugs remaining somewhere, but there isn't much to be done if it isn't reproducable. that error is particularly strange Dec 21 22:03:27 it could very well be a multiprocessing bug, hard to say Dec 21 22:04:04 kergoth_: ah, you are back. I just sent an email about base.bbclass breakage in BB 1.8.19 Dec 21 22:04:25 i was doing builds all day the other day with 1.8 in git Dec 21 22:04:48 eFfeM: np, thanks for testing Dec 21 22:04:50 cleaning the cache did not make the problem go away Dec 21 22:05:47 denix: will take a look at it when it shows up in my inbox Dec 21 22:05:48 kergoth_: here's what I'm seeing - http://pastebin.com/bnkLpm7f Dec 21 22:06:16 yeah, mailing list is super slow today - my emails take at least an hour to show up... Dec 21 22:06:27 denix: that's fixed. Dec 21 22:06:33 not in a release yet, but its fixed in git Dec 21 22:06:35 ok, calling it a day, have fun everyone! Dec 21 22:06:39 1.8 branch has a few new fixes Dec 21 22:06:55 kergoth_: ah, in bitbake? missed that Dec 21 22:07:10 yes, it was a bug in bb.warn Dec 21 22:07:31 will see about doing a new 1.8 release soon Dec 21 22:07:40 should probably do a new 1.10 also Dec 21 22:07:47 it has a few fixes too Dec 21 22:08:16 thanks! that would be great Dec 21 22:24:48 denix: also, you should really try out master, its leaps and bounds faster than 1.8, and it could always use more testers ;) Dec 21 22:26:18 re obi Dec 21 22:29:13 hi woglinde Dec 21 22:41:51 hi likewise Dec 21 22:42:02 hi woglinde, all Dec 22 02:58:14 khem, FYI, I've been doing some mipsel builds with your recent linaro gcc patches. No ICEs... **** ENDING LOGGING AT Wed Dec 22 02:59:57 2010