**** BEGIN LOGGING AT Tue Jun 30 02:59:57 2009 Jun 30 06:39:28 morning folks Jun 30 06:53:01 great, even with the defconfig from /proc/config.gz my kernel crashes (same kernel-version!) Jun 30 07:02:34 I get an error message "/bin/sh: arm-linux-gcc: command not found" when trying to build u-boot for a custom board. How can I get OE to build the needed tools? Jun 30 07:05:36 Viltapi: "bitbake u-boot" doesn't work? Jun 30 07:08:05 Treibholz: nope, the problem is that I need to build u-boot with a different toolchain than the rest of the image Jun 30 07:09:07 because if I only try "bitbake u-boot" i get "arm-angstrom-linux-gnueabi-ld: ERROR: Source object .../build/tmp/cross/arm/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc.a(_udivdi3.o) has EABI version 4, but target u-boot has EABI version 0" Jun 30 07:09:50 and to solve that i read that i should be using arm-linux-gcc instead of arm-angstrom-linux-gnueabi Jun 30 07:12:15 i made a change so that it tries to use the right chain but i don't know how to get OE to build it first Jun 30 07:15:29 Viltapi: maybe the easiest thing is to use a second environment. Jun 30 07:17:50 Treibholz: hmm, but still, how would i get OE to build those tools needed for building u-boot even in that second environment? Jun 30 07:22:28 morning Jun 30 07:52:12 how do I force at dependency to NOT compiel the latest and greatest verson ? Jun 30 07:57:54 fx. if I have sw1_1.2.bb and sw1_1.3.bb how can I then force "build sw1" to build version 1.2 ? Jun 30 08:02:25 PREFERRED_VERSION_sw1 = "1.2" Jun 30 08:03:46 sgh: or you could add a line: DEFAULT_PREFERENCE="" in the 1.2 recipe Jun 30 08:04:15 oespirit: thank you ... It seems to be missing in the manual ... Jun 30 08:04:32 sgh: I found it in the manual :) Jun 30 08:05:10 oespirit: argh .. http://bec-systems.com/oe/html/index.html ? Jun 30 08:06:36 sgh: errr...dont know about that one. I read it here : http://docs.openembedded.org/usermanual/usermanual.html Jun 30 08:07:59 oespirit: thanks ... seems to be more complete Jun 30 08:08:25 sgh: yup, its the "official manual" as the main site says :) Jun 30 08:08:42 oespirit: I'll use that from now on Jun 30 08:55:58 hi all Jun 30 09:18:30 hello florian Jun 30 09:28:58 while editing a general makefile to add an OE recipe for it, is it ok to use OE variables (something like ${STAGING_BINDIR}) and OE-style soft assignments in the Makefile? Jun 30 09:29:45 florian: good morning Jun 30 10:31:43 hrm Jun 30 10:32:11 has OE the capability to have some kind of bookkeeping to redo compilations with a certian toolchain, certain packages Jun 30 10:32:19 so that it's guaranteed it does the same verytime? Jun 30 10:32:24 or rahter, the output is the same Jun 30 10:32:38 or like, being able to revert back Jun 30 10:32:50 or if so, you have to have to use tags with an SCM or whatever Jun 30 11:29:56 03Jeremy Lainé  07org.openembedded.dev * r62e92c381d 10openembedded.git/recipes/linux/linux_2.6.29.bb: linux-2.6.29: remove SQN11xx hack for boc01 Jun 30 12:07:50 I want to ask a stupid question... if I want to add a package X I would use bitbake X but the problem is... Jun 30 12:08:42 how do I know what X is called? where can I find a list of packages available? perhaps I am missing something in my understanding? Jun 30 12:16:39 morning Jun 30 12:17:37 hi hrw Jun 30 12:24:58 good afternoon Jun 30 12:25:05 sasa bitbake -s shows all available versions for example Jun 30 12:25:13 all preferred versions at least Jun 30 12:47:35 florian: looks like ATI radeon support improved a lot since I looked at it last time Jun 30 12:47:42 Hi Gnutoo Jun 30 12:47:48 hi Jun 30 12:47:59 hrw: do you have a candidate already? Jun 30 12:48:17 mario-goulart, yesterday I realized that I was doing something wrong with gdb Jun 30 12:48:18 Gnutoo: I see you could run gdbserver on your mips system. Jun 30 12:48:29 florian: no - just checked my wife's laptop Jun 30 12:48:36 :-) Jun 30 12:48:46 Gnutoo: what a coincidence. I was about to ask about it. :-) Jun 30 12:48:49 mario-goulart, I was doing gdbserver 168.0.0.139 chroot /mnt/NFS /bin/hello Jun 30 12:48:49 florian: its 2.5 year old celeron based one but with ATI RS482 chipset Jun 30 12:49:04 mario-goulart, but I was doing file hello Jun 30 12:49:21 mario-goulart, I'll try that when my new rootfs witll be ready: Jun 30 12:49:53 mario-goulart, chroot gdbserver 168.0.0.139:8022 /bin/hello Jun 30 12:49:58 florian: I have another thing to add to the list :( Jun 30 12:50:03 Gnutoo: ok. I don't know gdbserver. I'll take a look at that. Jun 30 12:50:30 hrw: did you have ssd in there? Jun 30 12:50:58 * XorA begins to think a successful trac installation relies more on luck than any goodness in the code Jun 30 12:51:50 XorA: The interesting job starts after this - there are soo many projects with incredibly bad websites using trac out there. Jun 30 12:52:34 florian: I have found a way to break trac using mod_python, which doesnt show up in mod_python and generates no sensible error logs Jun 30 12:52:45 doesnt show up in tracd Jun 30 12:52:52 mario-goulart, my compiler is broken so I am bitbaking a new rootfs it will take some time Jun 30 12:53:08 Gnutoo: right. Jun 30 12:53:12 mario-goulart, but as I'm compiling the micro-base-image it will be faster Jun 30 12:53:12 florian: no Jun 30 12:53:22 florian: SSD bumps cost too much Jun 30 12:53:35 Gnutoo: did you have problems when building readline for mips? Jun 30 12:53:39 * XorA has 40G of ssd Jun 30 12:53:54 mario-goulart, don't know...is it part of the micro-base-image? Jun 30 12:53:56 hrw: you have a little daughter :) Jun 30 12:54:15 Gnutoo: as far as I can see, it's a dependency for gdbserver Jun 30 12:54:34 mario-goulart, ah ok...I'll look when it will be cross-compiled Jun 30 12:54:42 Gnutoo: at least it poped up when I added gdbserver to the IMAGE_INSTALL var Jun 30 12:54:46 mario-goulart, because my old gdbserver came from openwrt Jun 30 12:54:53 Gnutoo: ah, ok. Jun 30 12:54:54 mario-goulart, ok Jun 30 12:59:34 florian: which is not allowed to be in this room Jun 30 13:00:26 hrw: ok, i use my laptop everywhere :) Jun 30 13:03:03 I'm having a problem with a xapian-bindings-python recipe I'm trying to write: xapian-bindings uses autotools and the configure checks for the existance of Python.h in the directory found by doing $PYTHON -c 'import os,distutils.sysconfig;print(distutils.sysconfig.get_python_inc().replace(os.sep,"/"))' Jun 30 13:04:09 building for the beagleboard, this directory is $TMP/staging/arm-angstrom-linux-gnueabi/usr/include/python2.6 with just arm instead of armv7a Jun 30 13:04:50 where arm-angstrom-linux-gnueabi is taken by python from HOST_SYS Jun 30 13:07:29 should I patch the configure to take the directory from an env variable or what? Jun 30 13:08:07 03ghost  07org.openembedded.dreambox * rbc9dc9612e 10openembedded.git/packages/dreambox/dreambox-dvb-modules.bb: Jun 30 13:08:07 dreambox-dvb-modules.bb: new dm800 drivers to fix progressive/interlaced detection Jun 30 13:08:07 and strange scaling effects on channel change Jun 30 13:11:37 or how safe would it be to put HOST_SYS=${MULTIMACH_HOST_SYS} autotools_do_configure in the do_configure ()? Jun 30 13:14:22 Gnutoo: I've built openwrt's system with V=99 (verbose) so I can see how things are build. Maybe we can find something comparing OE's and openwrt's builds. Jun 30 13:15:21 I have this problem: ERROR: see log in /home/matt/beagle/OE/angstrom-dev/work/x86_64-linux/glib-2.0-native-2.18.0-r4/temp/log.do_stage.22846... Jun 30 13:15:53 when building with bitbake. I don't know what to do about it or how to debug any advice? Jun 30 13:16:31 sasa: did you do as it suggests and see the log? Jun 30 13:17:57 hmm.. looks like I need to patch include/linux/pci_ids.h Jun 30 13:18:15 mario-goulart, ok Jun 30 13:19:01 Yes the log didn't enlighten me: one line of interest: FATAL: oe_libinstall: gobject/.libs/libgobject-2.0.so.0.1800.0 not found... Jun 30 13:23:48 hi, I need to customize etc/X11/Xserver on target machine AT91SAM9, I edited recipes/xserver-kdrive-common/xserver-kdrive-common/Xserver but my settings don't go into the filal image Jun 30 13:23:55 http://patchwork.openembedded.org/patch/800/ Jun 30 13:24:11 where do I have to add such setting? Jun 30 13:24:46 * florian shoots xserver-kdrive-common Jun 30 13:25:19 mckoan: depending on the image you built you get xserver-common or xserver-kdrive common into the image :-( Jun 30 13:25:51 florian: MACHINE=ronetix-pm9263; bitbake x11-image Jun 30 13:26:19 hmm... x11-image should be xserver-kdrive-common Jun 30 13:26:48 mckoan: did you increment PR? Jun 30 13:29:12 florian: not yet Jun 30 13:29:45 mckoan: then you need to make sure that the package get built with the changes Jun 30 13:29:51 +s Jun 30 13:30:15 florian: PR bump involves the building flow or it is required only from patching rules? Jun 30 13:30:47 florian: what does '+s' mean? Jun 30 13:31:54 mckoan: it indicates that there is a change which will result in a differnt package then the revision before. oe looks for this to decide if a package needs to be build again Jun 30 13:32:22 mckoan: there was an 's' missing in the sentence before Jun 30 13:33:12 mckoan: bitbake xserver-kdrive-common -c clean will make oe to build it again even without changing PR Jun 30 13:33:43 sasa: well, that error sounds fairly clear. I guess you need to inspect the other logfiles to find out why the library isn't in the place where it's expected. Jun 30 13:35:50 since it's referring to gobject/.libs/libgobject-2.0.so.* it sounds like the build of gobject itself failed to build libgobject.so Jun 30 13:37:50 florian: I have even done a complete remuild (deleting tmp) unsuccessfully Jun 30 13:38:04 s/remuild/rebuild Jun 30 13:38:25 florian: BTW I'm trying xserver-kdrive-common -c clean as you suggested Jun 30 13:38:40 Caelian: indeed, it seems. Jun 30 13:40:13 mckoan: ok... scary... does this image maybe use xserver-nodm-init?! Jun 30 13:41:22 i am having fun trying to work through defining and configuring a completely new OE-based distro for our own internal purposes at work ... it's been educational so far :) Jun 30 13:45:51 where is created the root filesystem image before it is packed into a jffs2 ? Jun 30 13:46:11 $OE/tmp/somwhere Jun 30 13:51:05 mckoan: $TMPDIR/rootfs Jun 30 13:52:15 florian: it's empty, why? Jun 30 13:53:49 mckoan: you have a jffs2 image but no $TMPTIR/rootfs/ subdir? Jun 30 13:56:00 florian: yes Jun 30 13:57:28 03David Batzle  07org.openembedded.dev * r5b5a19ac03 10openembedded.git/recipes/irrlicht/ (files/irrlicht_beagle.diff irrlicht-examples-gles.bb): irrlicht: add recipe to build irrlicht demos against a GLES1.1 lib Jun 30 13:57:46 * florian scratches head Jun 30 13:58:21 florian: recently we commited change to drop tmp/rootfs after creation of image Jun 30 13:58:34 mckoan: IMAGE_FSTYPES += "tar" in local.conf Jun 30 13:59:02 hrw: Jun 30 13:59:08 hrw: oops... why this? Jun 30 13:59:25 hrw: I have the usual IMAGE_FSTYPES += "tar.bz2 ext2 jffs2" Jun 30 13:59:38 too many people expect tmp/rootfs to be real FS Jun 30 13:59:49 mckoan: so check in tar.bz2 then Jun 30 14:01:32 hrw: I don't get the point here... so we could have changed it in this way - now people will complain that rootfs is empty Jun 30 14:02:05 having the last created rootfs in this directory was very useful for soem fast checks Jun 30 14:02:10 florian: they can check that commit to discover that there is variable for it Jun 30 14:03:07 hrw: this won't stop people from thinking rootfs is empty Jun 30 14:03:21 heh.. I love situations when 'ssh remote.machine' hangs after login Jun 30 14:03:48 apart from the fact that it is likely that documetation still refers to rootfs as the directory with the latest filesystem Jun 30 14:03:57 florian: if I will commit patch which will move TMP/rootfs to WORKDIR/rootfs (where it should be from start imho) will they complain too? Jun 30 14:04:04 I woild prefer the rootfs fast check way +1 from me Jun 30 14:04:27 mckoan: then 'git log' rootfs change and read commit message Jun 30 14:04:39 and for future: read OE ML more often guys Jun 30 14:05:10 anyway the modification I did aren't in the final image yet :-( Jun 30 14:05:32 recipes/xserver-kdrive-common/xserver-kdrive-common/Xserver is ignored Jun 30 14:05:43 hrw: yes that would be a good idea - way more sane than the solution before. but we need to make sure that we change documentation too... Jun 30 14:06:22 mckoan: you do that on your quad? Jun 30 14:06:31 hrw: yes Jun 30 14:06:55 which dir? Jun 30 14:07:15 /home/koan/devel/openembedded/recipes/xserver-kdrive-common/xserver-kdrive-common/Xserver Jun 30 14:07:48 mckoan: and which build tree? Jun 30 14:08:03 build tree? Jun 30 14:08:29 where you do image build Jun 30 14:08:56 ok, found Jun 30 14:09:15 /home/koan/devel/build/kaeilos/tmp/deploy/glibc/images/ronetix-pm9263 Jun 30 14:09:35 look into x directory which is the bz2 upacked Jun 30 14:10:00 mckoan: this image uses xserver-common not xserver-kdrive-common Jun 30 14:10:52 and yes, this situation suxx (2 packages doing same) Jun 30 14:17:31 hrw: how you deduce it from? Jun 30 14:23:11 /usr/lib/opkg/status ;D Jun 30 14:23:15 * hrw -> out Jun 30 14:23:16 bbl Jun 30 14:30:41 hrw|gone: very useful file, thx Jun 30 14:48:06 Gnutoo: have you noticed that openwrt's /lib doesn't have libpthread.so.0? Jun 30 14:48:20 mario-goulart, no I didn't notice Jun 30 14:48:42 mario-goulart, but look at openwrt result with file or readelf... Jun 30 14:48:50 Gnutoo: I _think_ I'm using the same config for OE's uClibc. Now I'm not sure. Jun 30 14:48:52 mario-goulart, you can't see the sections Jun 30 14:51:48 Gnutoo: I'm cat'ing openwrt's common and mips files (from trunk/toolchain/uClibc/config-0.9.30.1) into OE's uClibc.machine. I suppose OE is using this config file, but the end result is quite different. Jun 30 14:52:11 mario-goulart, I already played with uclibc's config Jun 30 14:52:28 mario-goulart, basically it's composed of 2 parts Jun 30 14:52:42 mario-goulart, I don't remember well but maybe it's distro and machine config Jun 30 14:52:50 Gnutoo: yeah Jun 30 14:53:01 and they are assembled together to do the config that will be used Jun 30 14:53:23 Gnutoo: ahm ok. That's what I'm doing manually. Jun 30 14:53:33 ok Jun 30 14:53:59 what do you mean by manually? Jun 30 14:55:07 Gnutoo: I join openwrt's common and mips file (the config files for uclibc) into uClibc.machine (for OE). Jun 30 14:55:32 Gnutoo: so OE uses uClibc.machine which is openwrt's common and mips concatenated. Jun 30 14:55:57 Gnutoo: OE's uClibc.distro is empty Jun 30 14:56:29 Gnutoo: but it's weird that openwrt's /lib doesn't have libpthread, since: Jun 30 14:56:43 $ grep THREAD common mips Jun 30 14:56:43 common:# HAS_NO_THREADS is not set Jun 30 14:56:43 common:LINUXTHREADS_OLD=y Jun 30 14:56:43 common:# PTHREADS_DEBUG_SUPPORT is not set Jun 30 14:56:46 common:UCLIBC_HAS_THREADS=y Jun 30 14:56:49 Jun 30 14:58:21 Gnutoo: and OE's /lib does have libpthread. OE is supposed to be using the same configuration as openwrt. Jun 30 14:58:48 Gnutoo: ... unless some mangling is in effect (uclibc.inc does some). Jun 30 14:59:18 yes unless it sed the config Jun 30 14:59:46 like for CONFIG_CMDLINE in the kenrel recipes Jun 30 15:00:04 Gnutoo: just checked the merged.config file under OE's workdir for uClibc and it's the expected one (with threads) Jun 30 15:00:15 ok Jun 30 15:00:54 Gnutoo: so probably openwrt does some mangling. Jun 30 15:01:23 Gnutoo: I'm going out for lunch. See you later. Jun 30 15:01:31 ok bye see you later Jun 30 15:02:39 g'day kergoth Jun 30 15:02:53 hey pb_ Jun 30 15:15:09 I am having problems with OE and bitbake building images for the beagleboard... Jun 30 15:15:48 I don't really know what I am doing but bitbake seems to be choking on building perl for x86_64 and I don't Jun 30 15:16:06 understand why it is trying to build x86 packages... Jun 30 15:17:06 bitbake says: TARGET_ARCH = "arm", TARGET_OS = "linux-gnueabi" and then throws this error: Jun 30 15:17:19 ERROR: Build of /home/matt/beagle/OE/openembedded/recipes/perl/perl-native_5.8.8.bb do_populate_staging failed Jun 30 15:17:53 NOTE: Task failed: /home/matt/beagle/OE/angstrom-dev/work/x86_64-linux/perl-native-5.8.8-r13/temp/log.do_stage Jun 30 15:18:18 but I don't know why it is trying to build the x86_64 versions - any suggestions? Jun 30 15:18:21 sasa: it's a -native build. there are lots of -native recipes that are built because they're needed by the crosscompiles. Jun 30 15:19:27 kergoth: so you are saying bitbake is building perl on the x86 host so it can go onto to use this to build packages for the bb? Jun 30 15:20:56 I have (a newer version) of perl install on the x86 box, I'm not sure I understand what is going on... Jun 30 15:21:08 it's likely building perl on x86 because it needs that exact version in order to build perl for your target, sasa. you can use bitbake -g to get a graphviz graph of the dependencies, so you can see what's depending on it Jun 30 15:21:26 this isn't that hard to understand, how many times do i have to explain it? Jun 30 15:21:54 we can't rely on every machine having these things, lots of recipes have very specific build system dependencies Jun 30 15:22:06 if you think you have the version it needs, you can use ASSUME_PROVIDED to declare that your system already provides that functionality Jun 30 15:22:24 but you have to be careful there, some things, like autoconf-native, are patched, and we require the patched version Jun 30 15:22:52 ASSUME_PROVIDED += "somerecipe-native" would be the syntax, if you want to try to use it, but generally speaking you're on your own when using it, won't get support if it breaks something :) Jun 30 15:24:45 Ok - I understand this point but it won't build perl so I am slightly stuffed at this point... Jun 30 15:25:30 so analyse the error Jun 30 15:26:16 right, you'd get that same failure building that version of perl outside of OpenEmbedded, the failure is just a native perl build failure. Jun 30 15:27:45 Yep - I have been trying to fix this now for some time - where does the ASSUME_PROVIDED += "somerecipe-native" thing go (local.conf)? Jun 30 15:28:23 and somerecipie is a pointer to the local perl presumably (syntax?)? Jun 30 15:28:30 "pointer"? Jun 30 15:28:47 ASSUME_PROVIDED += "perl-native" Jun 30 15:28:50 gosh, thats was difficult Jun 30 15:29:21 Thanks for the sarcasm it really helps a lot Jun 30 15:29:42 anytime Jun 30 15:29:53 if you don't know what a recipe is, or what its name is, you haven't read the manual Jun 30 15:30:04 so you should expect things like sarcasm when that's the case Jun 30 15:41:02 re Jun 30 15:41:08 ~curse toshiba l30 laptop Jun 30 15:41:09 May you be reincarnated as a Windows XP administrator, toshiba l30 laptop ! Jun 30 15:41:12 hey hrw Jun 30 15:43:28 ~curse notebook vendors for crappy audio used Jun 30 15:43:29 May you be reincarnated as a Windows XP administrator, notebook vendors for crappy audio used ! Jun 30 15:44:15 snd-hda-intel is full of quirks and anyway it does not play on l30 here Jun 30 15:49:24 03Koen Kooi  07org.openembedded.dev * r0c88cc6cb7 10openembedded.git/ (3 files in 2 dirs): lirc: update to 0.8.5 Jun 30 15:49:35 03Koen Kooi  07org.openembedded.dev * rdc6b5e5729 10openembedded.git/recipes/mythtv/mythtv_0.21.bb: Jun 30 15:49:35 myththv: bump SRCREV Jun 30 15:49:35 * this fixes the "people look like smurfs" bug: http://svn.mythtv.org/trac/ticket/5670 Jun 30 16:09:56 I've got a recipe for an out-of-tree kernel module that I'm trying to build against 2.6.29 (previously I was at 2.6.26) - its looking like the staging tree is not correct for the 2.6.29 kernel - does this sound like a familiar issue? Jun 30 16:11:48 things are changing in kernel land Jun 30 16:12:59 in a devshell I can build the module using kernel path of the kernel workdir, but when I point to the staging dir there are massive kernel header issues Jun 30 16:14:17 aren't the headers in staging the sanitized headers for userland to make use of, not kernel code? Jun 30 16:14:24 or am i remembering wrong? Jun 30 16:14:53 not sure... I've always build this out-of-tree module using staging... its a customized madwifi module Jun 30 16:14:59 I'd expect so, yes - you should be building against an actual kernel tree. Jun 30 16:15:07 or I should say I've always built it against 2.6.26 that way Jun 30 16:15:26 There's work going on to sanities the glibc copies of the headers which is likely what you're seeing. Jun 30 16:17:00 the current madwifi recipes in oe do the same as I though - KERNELPATH=${STAGING_KERNEL_DER} - is it possible that nobody is building oe's madwifi for 2.6.29+? Jun 30 16:18:03 broonie, are you suggesting that I point the kernel path to the kernel workdir then and 'not' staging? or is there 2 staging dirs: one for userland and another for kernel modules? Not sure what OE var to use for kernel's workdir Jun 30 16:18:40 There's probably two staging dirs. Jun 30 16:20:10 I see only 1 machine specific kernel headers dir in staging though... would make sense for there to be two Jun 30 16:23:59 I see several out-of-tree kernel module recipes using KERNDIR=${STAGING_KERNEL_DIR} Jun 30 16:24:48 http://bec-systems.com/oe/html/directories_staging.html - shows there is only one kernel staging dir so if there does need to be a split for userspace/kernel it hasn't been done yet Jun 30 16:36:09 mario-goulart, unfortunately I've forgetten to add -ggdb3 to my build Jun 30 16:36:33 mario-goulart, but it sefault at the last line here: http://pastebin.com/m7fbbad85 Jun 30 16:40:28 tharvey: ah, right, STAGING_KERNEL_DIR is the actual kernel headers, the sanitized ones would be in the normal staigng include & lib dirs, or the cross dirs Jun 30 16:40:32 mario-goulart, t9 is 2aab0394 Jun 30 17:10:34 Gnutoo: I don't know much about mips assembly. Is t9 a register? Jun 30 17:10:51 yes Jun 30 17:10:58 temporary register Jun 30 17:11:27 Gnutoo: ah, ok. You mean there's a jump to an invalid location? Jun 30 17:11:47 yes Jun 30 17:12:23 Gnutoo: hmmm. Any idea about who's generating this invalid code? Jun 30 17:12:30 no Jun 30 17:12:34 I've no idea Jun 30 17:12:51 My woes using bitbake look like they result from this bug: http://bugs.openembedded.org/show_bug.cgi?id=4396... Jun 30 17:13:56 Gnutoo: anyway, you've spot a good track. Now we have something from where we can start looking for a solution. Jun 30 17:13:58 the patch failed to help but Oliver Eichler's fix seems to work, we'll see once the build completes. Jun 30 17:14:15 ok Jun 30 17:14:37 Gnutoo: you are using OE's rootfs, right? Jun 30 17:15:18 mario-goulart, openwrt's rootfs->chroot->static-gdb->hello-world Jun 30 17:16:07 Gnutoo: hmmm. Jun 30 17:16:50 Gnutoo: can't you run any binary under openwrt system (rootfs)? Jun 30 17:17:16 Gnutoo: here things work on openwrt. I just can't make them work on OE. Jun 30 17:17:30 mario-goulart, openwrt+hello world runs fine Jun 30 17:17:56 mario-goulart, oe+any shared lib => segfault Jun 30 17:18:22 Gnutoo: ah, ok. Same here. Jun 30 17:18:22 mario-goulart, openwrt->chroot->hello-world-dynamic => segafault Jun 30 17:18:26 yes Jun 30 17:18:33 I should have added -ggdb3 Jun 30 17:19:51 Gnutoo: maybe -O0 too. Jun 30 17:21:48 mario-goulart, ok Jun 30 17:49:05 03Koen Kooi  07org.openembedded.dev * rcbe3798f41 10openembedded.git/recipes/sugar/sugar-base_0.83.2.bb: sugarbase: inherit gnome for gconf and icon helpers Jun 30 18:14:28 03Koen Kooi  07stable/2009 * r2cdd6a46e9 10openembedded.git/ (3 files in 2 dirs): Jun 30 18:14:28 lirc: update to 0.8.5 Jun 30 18:14:28 Signed-off-by: Koen Kooi Jun 30 18:14:28 Acked-by: Tom Rini Jun 30 18:14:28 Acked-by: Denys Dmytriyenko Jun 30 18:14:38 03Koen Kooi  07stable/2009 * r0671845b9f 10openembedded.git/recipes/mythtv/mythtv_0.21.bb: Jun 30 18:14:38 myththv: bump SRCREV Jun 30 18:14:39 Signed-off-by: Koen Kooi Jun 30 18:14:41 Acked-by: Tom Rini Jun 30 18:14:43 Acked-by: Denys Dmytriyenko Jun 30 18:20:43 03Ottavio Campana  07org.openembedded.dev * r378be0dcdc 10openembedded.git/ (conf/checksums.ini recipes/live555/live555_20090602.bb): Jun 30 18:20:43 live555: update to 2009.06 Jun 30 18:20:43 Signed-off-by: Koen Kooi Jun 30 18:20:53 03Koen Kooi  07org.openembedded.dev * rbb6a5a722b 10openembedded.git/recipes/u-boot/ (u-boot-git/new-pinmux.patch u-boot_git.bb): u-boot git: update beagleboard pinmux Jun 30 18:31:42 re Jun 30 19:12:21 03Denys Dmytriyenko  07stable/2009 * r1ad4b80ab4 10openembedded.git/recipes/base-files/base-files/profile: Jun 30 19:12:21 /etc/profile: stricter root PATH - require absolute pathname for bins in cwd Jun 30 19:12:21 Having current directory (either '.' or empty string) in PATH is considered Jun 30 19:12:21 dangerous for root. Jun 30 19:12:21 Signed-off-by: Denys Dmytriyenko Jun 30 19:12:23 Acked-by: Phil Blundell Jun 30 19:12:27 Acked-by: Koen Kooi Jun 30 19:24:32 kergoth, yes, KERNEL_STAGING_DIR is definately where out-of-tree modules should point to for kernel headers - yet I find that madwifi builds only for 2.6.29 if I point to KERNEL_SOURCE instead... still not clear why Jun 30 19:49:06 Hi, all! If I have big NAND (2GB), big jffs2 image (256MB), and a small (64MB) amount of RAM. Is there some way to flash this image to NAND using u-boot on such a system? Jun 30 19:50:14 that's not really on topic, this channel is about the use of openembedded and bitbake, but then, I'm not sure of a better channel to ask it in, so i guess that works :) Jun 30 19:50:24 could try #edev Jun 30 19:51:01 it is actually related to openembedded-generated image :) Jun 30 19:52:08 slapin_nb: I suppose you could split the image to chunks of <64MB and flash a chunk at a time Jun 30 19:52:39 that doesn't make it on topic. the question would be the same regardless of what image you were using :) Jun 30 19:52:52 not that it matters, really, just noting it Jun 30 19:52:59 akheron, is there some automated tools to script that? Jun 30 19:53:34 * slapin_nb is really sorry for polluting channel with off-topic questions Jun 30 19:53:58 well it's not like you're interrupting anything, it's dead in here :) Jun 30 19:54:02 slapin_nb: I have no idea, I've never used nand Jun 30 19:54:18 or a system with less ram than non-volatile storage Jun 30 19:54:36 umm, such an embedded system I mean Jun 30 19:54:59 the laptop I'm using right now definitely has less ram than hard disk space :F Jun 30 19:55:34 akheron, thanks! I think I need to find good splitting tool and write script for u-boot Jun 30 19:56:03 dd and a tiny shell script should be okay for splitting Jun 30 20:22:10 03Denys Dmytriyenko  07org.openembedded.dev * r7ad802292d 10openembedded.git/ (2 files in 2 dirs): Jun 30 20:22:10 linux-davinci: update to the latest staging/vpfe branch Jun 30 20:22:10 Signed-off-by: Denys Dmytriyenko Jun 30 20:28:18 03Denys Dmytriyenko  07org.openembedded.dev * r60b572f455 10openembedded.git/recipes/linux/linux-davinci_2.6.30.bb: Jun 30 20:28:18 linux-davinci: add formal 2.6.30 version Jun 30 20:28:18 Signed-off-by: Denys Dmytriyenko Jun 30 20:36:12 03Denys Dmytriyenko  07org.openembedded.dev * r0f691ce323 10openembedded.git/MAINTAINERS: MAINTAINERS: add my entry Jun 30 21:06:21 anyone got any ideas on fixing the "multiple versions of bluez building" issue? Jun 30 21:06:47 I see pb_ and Laibsch were investigating a couple of weeks ago Jun 30 21:07:36 bluelightning: I kind of gave up Jun 30 21:07:45 I don't really want bluetooth anyway Jun 30 21:07:46 Laibsch: why's that? Jun 30 21:07:51 oh... ok Jun 30 21:07:57 so, that is the route I've taken for minimal Jun 30 21:08:19 make it not depend on the bluetooth stuff and let somebody who wants bluetooth worry about fixing the mess ;-) Jun 30 21:08:29 what distro are you building for? Jun 30 21:08:38 Laibsch: angstrom, as usual Jun 30 21:08:45 you can always apply the force-defaults patch locally Jun 30 21:08:59 that will at least give you an image Jun 30 21:09:00 force-defaults patch? Jun 30 21:09:13 I RFC'd it a couple of weeks ago Jun 30 21:09:46 it was rejected on the grounds that rather than cosmetics, the underlying problem should be fixed Jun 30 21:09:55 * Laibsch agrees with that assessment Jun 30 21:10:09 But I don't feel like fixing bluez in OE Jun 30 21:13:11 seems that few others have a handle on the issue either Jun 30 21:13:30 or indeed the inclination to bash on it until it is fixed (myself included) Jun 30 21:13:36 Isn't it a matter of setting up virtuals or similar for bluetooth? Jun 30 21:13:43 or just dropping bt3.x ? Jun 30 21:14:08 hi ant__ Jun 30 21:14:15 ant__: we are discussing bt issue atm Jun 30 21:14:40 ah.. the opkg-cl leaved the king naked... Jun 30 21:14:57 ant__: well, that's the end result yes Jun 30 21:15:22 can we suggest a quick fix to the poor guy in the ML? Jun 30 21:16:03 ant__: yes I think that would be a good start... Jun 30 21:16:31 bluelightning: I think I know how to 'repair'.. Jun 30 21:16:44 ant__: what's your suggestion? Jun 30 21:17:02 all come since bluez4 introduction Jun 30 21:17:11 we can override for opie Jun 30 21:17:23 well, opie is not a distro, I know Jun 30 21:18:18 for opie, I'd go back to bluez3 and have a working opie, then move to bluez4. Objections? Jun 30 21:19:03 hi, is it true that the palm pre uses directfb? Jun 30 21:19:03 ant__: none from me, assuming that no other os-level components now depend on bluez4 - I haven't checked Jun 30 21:19:20 because http://en.wikipedia.org/wiki/Directfb says it's LGPL Jun 30 21:19:53 bluelightning: I personally have only experience with bluez3 on real device (zaurus + cf bt) Jun 30 21:19:57 and http://opensource.palm.com/packages.html doesn't list directfb Jun 30 21:20:04 in both version Jun 30 21:20:59 ant__: I am just trying a build now with PREFERRED_VERSION_bluez-{utils|libs}=3.36 added to preferred-opie-versions-1.2.4.inc Jun 30 21:21:19 yea, something like this Jun 30 21:21:39 pb objected opie is not a distro and should just inherit Jun 30 21:21:54 but poor opie is soo old... Jun 30 21:22:15 could be considered a distro its alone Jun 30 21:22:17 I don't even know if it might just work straight away with bluez4 Jun 30 21:22:26 he Jun 30 21:22:35 but the annoying thing is unless I'm mistaken, no opie package asks for bluez3 explicitly Jun 30 21:22:46 so I don't know why it thinks it needs it :/ Jun 30 21:23:00 because distro(angstrom) sets it Jun 30 21:23:04 iirc Jun 30 21:23:17 doesn't it set preferred versions to 4.x? Jun 30 21:24:00 ah, sorry, you asked for 4 Jun 30 21:24:07 err for bluez3 Jun 30 21:24:32 it must be here... Jun 30 21:24:33 ./distro/include/preferred-om-2008-versions.inc:PREFERRED_VERSION_python-pybluez ?= "0.13" Jun 30 21:24:33 ./distro/include/preferred-opie-versions.inc:PREFERRED_VERSION_opie-bluepin ?= "${OPIE_VERSION}" Jun 30 21:24:33 ./distro/include/preferred-opie-versions.inc:PREFERRED_VERSION_opie-bluetoothapplet ?= "${OPIE_VERSION}" Jun 30 21:24:33 ./distro/include/preferred-opie-versions.inc:PREFERRED_VERSION_opie-bluetoothmanager ?= "${OPIE_VERSION}" Jun 30 21:24:33 ./distro/include/preferred-opie-versions.inc:PREFERRED_VERSION_opie-securityplugin-blueping = "${OPIE_VERSION}" Jun 30 21:25:33 the reason is that bluez4 does not provide everything that is needed Jun 30 21:25:42 look into bluez-cups-backend for example Jun 30 21:25:51 I spent quite some time looking into this Jun 30 21:26:02 Laibsch: there must be others it doesn't provide, because I don't need bluez-cups-backend Jun 30 21:26:05 removing bb files and looking what broke ;-) Jun 30 21:26:13 In the end, I just gave up ;-) Jun 30 21:26:42 is there a way for bitbake to output dependency chains or something like that? Jun 30 21:26:43 bluelightning: remove the bb files, it's the only sane way to find out what depends on it Jun 30 21:26:57 bitbake -g is supposed to do that Jun 30 21:27:03 But I don't think it is complete Jun 30 21:27:10 It was not sufficient for my analysis Jun 30 21:27:13 bluelightning: also try with -DDD or -vv Jun 30 21:27:13 argh Jun 30 21:27:25 or just remove the file Jun 30 21:27:27 ;-) Jun 30 21:27:34 Easiest and certain to work Jun 30 21:27:37 trust me Jun 30 21:29:35 well first I'll just make sure this hack works so I can answer the ml posting Jun 30 21:29:52 damn it I need a faster machine :/ Jun 30 21:32:33 angstrom ml? Jun 30 21:32:43 yes Jun 30 21:34:16 hm ...trying PREFERRED_PROVIDER_bluez-libs = "bluez3" and PREFERRED_PROVIDER_bluez-utils = "bluez3" in preferred-opie-versions-1.2.4.inc Jun 30 21:36:18 seems have done the job... Jun 30 21:36:24 now the second one... Jun 30 21:36:25 NOTE: multiple providers are available for opkg (opkg, opkg-nogpg, opkg-nogpg-nocurl); Jun 30 21:36:25 NOTE: consider defining PREFERRED_PROVIDER_opkg Jun 30 21:37:43 bluelightning: I think it's a PROVIDER problem, not just VERSION Jun 30 21:38:57 why the heck doesn't angstrom already define that? Jun 30 21:39:22 mmm CONFIG_MIPS_O32_ABI=y # CONFIG_MIPS_N32_ABI is not set Jun 30 21:39:37 Gnutoo: nice... Jun 30 21:39:46 bluelightning, ? Jun 30 21:40:01 bluelightning, are you involved in uclibc mips problems too? Jun 30 21:40:04 Gnutoo: manually hacked kernel config Jun 30 21:40:12 bluelightning, no uclibc config Jun 30 21:40:22 Gnutoo: no, just commenting randomly, sorry :) Jun 30 21:40:28 bluelightning, ah ok Jun 30 21:40:34 bluelightning, :) Jun 30 21:42:21 angstrom generally wants to move to bluez4, that is why those things are not defined as above Jun 30 21:42:48 bluelightning: ./rootfs_ipk.bbclass:IPKG_VARIANT ?= "opkg" Jun 30 21:42:59 trying to get bluez4 working as expected at compile time is a more worthwhile task than trying to coerce the build into bluez3 Jun 30 21:43:14 that's the second step Jun 30 21:43:21 noe it's broken and we repair Jun 30 21:43:38 by breaking other things Jun 30 21:43:40 Laibsch: I don't disagree, I was just after a quick temporary fix Jun 30 21:43:48 understood Jun 30 21:44:04 the quick temporary fix is the force-defaults patch I mentioned Jun 30 21:44:08 MUCH quicker, too Jun 30 21:44:29 anything else is fine locally, but not for being committed Jun 30 21:44:54 Laibsch: bluez4 come *years* after opie Jun 30 21:44:55 defining bluez preferences in opie is NOT ok Jun 30 21:45:05 that has no relevance here Jun 30 21:45:16 a lot of the things in building for OE today are more recent Jun 30 21:45:19 have you reports 'it works' ? Jun 30 21:45:31 I have for bluez3 Jun 30 21:45:37 ant? Jun 30 21:45:49 the force-default patch works fine Jun 30 21:45:58 nobody has tested opie+bluez4 Jun 30 21:46:05 99% won't work Jun 30 21:46:07 and the BTS has the information on what should be done to properly fix bluez Jun 30 21:46:09 oob Jun 30 21:46:25 we are talking compile-time problems now Jun 30 21:46:45 iirc you were discussing with pb about utils/libs Jun 30 21:46:48 if opie and bluez4 don't get along the proper thing is to RCONFLICT Jun 30 21:46:48 split Jun 30 21:46:53 not the stuff you are doing now Jun 30 21:47:10 yes, that is a very important thing in fixing this Jun 30 21:47:21 or make bluez4 provide -utils and -libs Jun 30 21:47:23 I think opie should be 'crystallized' with some sane working revisions Jun 30 21:47:29 and abandoned ... :) Jun 30 21:47:48 there is no development behind... Jun 30 21:47:56 ant__: ahem.... Jun 30 21:47:59 just bluelightning fixing as he can Jun 30 21:48:02 thx btw ;) Jun 30 21:48:09 :DD Jun 30 21:48:14 well, many projects are a one-man show Jun 30 21:48:25 well, I'm actually doing some real dev work atm... ok, so it's completing previous designs, but it's still real development Jun 30 21:48:30 no reason to "improperly fix" stuff Jun 30 21:48:33 (on opie I mean) Jun 30 21:48:37 nice to hear that Jun 30 21:48:38 cool Jun 30 21:49:15 but I haven't had time to add support for newer bluez interfaces (which require dbus) Jun 30 21:49:32 yea, the hal + dbus story.... Jun 30 21:50:01 it might not be hard, I don't know; I just haven't had time to properly investigate it Jun 30 21:50:17 I purposedly refuse to learn python... Jun 30 21:50:38 well, I would be using dbus C++ bindings here Jun 30 21:51:04 iirc there is a lot of work on that from Openmoko people Jun 30 21:51:31 don't know whether they merged all..or not Jun 30 21:52:00 openmoko latest work is unmerged but scheduled to merge Jun 30 21:52:09 ok, thx Jun 30 21:52:41 03Stanislav Brabec  07org.openembedded.dev * r814775d0a9 10openembedded.git/ (5 files in 3 dirs): libgmime: Packaged versions 2.2.23 (as libgmime) and 2.4.7 (as libgmime-2.4). Jun 30 22:05:56 bluelightning: about zaurusd, are you developer? Jun 30 22:06:11 wb Jun 30 22:06:13 bluelightning: about zaurusd, are you developer? Jun 30 22:06:37 argh @ ISP, must complain about bad connection Jun 30 22:07:02 ant__: not really, I submitted a patch for tskeys a while back but that's it Jun 30 22:07:20 I don't think it gets much maintenance these days Jun 30 22:08:00 oh, and I did bring it up to the latest svn rev in OE recently as well Jun 30 22:08:47 I see ... latest svn....some files are missing newline...git patches are horrible... Jun 30 22:09:10 and strangely I had to 'revert' one patch, just for borzoi... Jun 30 22:09:24 because was applied upstream (only for borzoi) Jun 30 22:09:59 there were some commits last weeks Jun 30 22:10:36 *cough* Jun 30 22:11:00 ant__: did you need something fixed on zaurusd? Jun 30 22:11:20 well, there are patches pending Jun 30 22:11:24 please give a look Jun 30 22:11:38 you mean those remaining in OE? Jun 30 22:11:45 yes Jun 30 22:11:50 hmm Jun 30 22:12:08 I suppoose zaurusd is only built in OE Jun 30 22:12:14 I would pester RP about that, but I'm not sure he has any time to review zaurusd patches Jun 30 22:12:45 anyway, look at the use-ts-symlink-ins~of-hardcoding.diff│ Jun 30 22:13:21 at least we should clear the issues like \ No newline at end of file Jun 30 22:13:40 :D Jun 30 22:15:36 bluelightning: oh..sorry Jun 30 22:15:57 I see now ..it's in avoid-rotated-server.patch Jun 30 22:17:20 hm..why only for borzoi ^^^ Jun 30 22:17:51 I'd revert here and susbt with touchscreen0 in the a.m. use-ts... patch Jun 30 22:20:04 * * OE Bug 5278 has been created by arne(AT)arne-koehn.de Jun 30 22:20:07 * * wrong SRC_URI for ttf-sazanami Jun 30 22:20:09 * * http://bugs.openembedded.org/show_bug.cgi?id=5278 Jun 30 22:20:23 ant__: yes, that one ought to go upstream Jun 30 22:20:38 03Denys Dmytriyenko  07org.openembedded.dev * rf73238a444 10openembedded.git/ (4 files in 3 dirs): alsa-utils: add 1.0.20 version Jun 30 22:34:42 03Andrea Adami  07org.openembedded.dev * r7354ce1960 10openembedded.git/recipes/zaurusd/files/ (2 files): Jun 30 22:34:42 zaurusd: rework patches Jun 30 22:34:42 - revert 8c942c2a74598c84dbe9646bbd6bbde6525ca53f Jun 30 22:34:42 - minimal fix to 35b530346188557e7b81bcb69ccea27f60766177 Jun 30 22:34:42 - s/event1/touchscreen0/ is done in a separate patch Jun 30 22:35:13 bluelightning: done, now please the newlines :P Jun 30 22:36:02 ant__: diff insisted on putting those in :/ Jun 30 22:36:17 even though there was no difference at that place in the file, IIRC Jun 30 22:36:42 the missing newlines are in the svn :/ Jun 30 22:36:59 ah right Jun 30 22:43:36 hm..do you remember that sh: rm not found Jun 30 22:43:52 see e.g. "opie-image.do_rm_work_all" -> "opkg.do_rm_work" Jun 30 22:44:15 "opie-image.do_rm_work_all" -> "opkg-native.do_rm_work" Jun 30 22:44:23 ... Jun 30 22:48:07 ant__: yes I think I've seen that before Jun 30 22:48:47 I suspect opkg situation is not optimal.... Jun 30 23:20:45 night Jun 30 23:21:09 03Denys Dmytriyenko  07org.openembedded.dev * rf35c640b68 10openembedded.git/recipes/gdb/gdbserver_6.6.bb: gdbserver: add 6.6 version - old, but GPLv2 Jun 30 23:21:49 03Koen Kooi  07org.openembedded.dev * r9628f84b91 10openembedded.git/ (2 files in 2 dirs): linux-omap 2.6.29: add support for mmc1 on expansion connector Jun 30 23:21:49 03Koen Kooi  07org.openembedded.dev * r9236bee440 10openembedded.git/ (4 files in 3 dirs): php-native: add 5.3.0 Jun 30 23:21:50 03Koen Kooi  07org.openembedded.dev * r107327eb91 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev Jun 30 23:21:51 03Koen Kooi  07org.openembedded.dev * r07c3c5d321 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev Jun 30 23:21:54 03Koen Kooi  07org.openembedded.dev * rcaa7a37b97 10openembedded.git/recipes/linux/linux-omap-2.6.29/beagleboard/tincantools-puppy.diff: linux-omap 2..29: add mising patch Jul 01 00:03:56 03Florian Boor  07org.openembedded.dev * rab81f3a9eb 10openembedded.git/conf/machine/tx25.conf: tx25.conf: Use correct kernel Jul 01 00:03:57 03Florian Boor  07org.openembedded.dev * r599bfe6146 10openembedded.git/recipes/linux/ (3 files in 2 dirs): linux: Remove broken tx25 support from 2.6.30 Jul 01 00:03:57 03Florian Boor  07org.openembedded.dev * r0eccce7f44 10openembedded.git/recipes/linux/ (4 files in 2 dirs): linux: Add 2.6.30-rc4 and necessary patches for tx25 **** ENDING LOGGING AT Wed Jul 01 02:59:57 2009