**** BEGIN LOGGING AT Mon Jun 06 02:59:57 2011
Jun 06 06:18:46 <CIA-8> 03Steffen Sledz <sledz@dresearch-fe.de> 07org.openembedded.dev * r637fb6589c 10openembedded.git/recipes/iotop/iotop_0.2.1.bb: 
Jun 06 06:18:46 <CIA-8> iotop: add missing runtime dependency
Jun 06 06:18:46 <CIA-8> Fixes runtime error:
Jun 06 06:18:46 <CIA-8> "No module named locale
Jun 06 06:18:46 <CIA-8> To run an uninstalled copy of iotop,
Jun 06 06:18:46 <CIA-8> launch iotop.py in the top directory"
Jun 06 06:18:46 <CIA-8> Signed-off-by: Steffen Sledz <sledz@dresearch-fe.de>
Jun 06 07:59:47 <mckoan> good morning
Jun 06 08:26:44 <bluelightning> morning all
Jun 06 08:33:28 <mckoan> bluelightning: hi
Jun 06 08:34:02 <bluelightning> hi mckoan
Jun 06 08:59:20 <mkneissl> How to get pthread stackframes in gdb? I get the following diagnostics: warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
Jun 06 09:17:23 <aarti> hi all, i have my customized recipe which was using ffmpeg, and was working fine i did git pull and now m building tht recipe again, oe is showing tht use libav, i have replaced ffmpeg and ffmpeg-dev with libav nd tried to compile my code it is showing so many missing header files error like avcodec.h is missing
Jun 06 10:05:02 <woglinde> hi obi
Jun 06 10:06:00 <obi> hi woglinde 
Jun 06 10:51:56 <drainbamage> hii i'm trying to build klibc with openembedded
Jun 06 10:52:14 <drainbamage> build fails in do_install
Jun 06 10:52:30 <drainbamage> it is trying to install klibc in my rootfs
Jun 06 10:52:55 <drainbamage> ERROR: function do_install failed ERROR: log data follows (/home/soulfood/thin/build/tmp/work/i586-linux/klibc-1.5.21-r0.0/temp/log.do_install.13992) | NOTE: make KLIBCARCH=i386 CROSS_COMPILE=i586-linux- KLIBCKERNELSRC=/home/soulfood/thin/build/tmp/staging/i586-linux/kernel install |   GEN     klcc/klcc |   INSTALL headers + man pages to /usr/lib/klibc | mkdir: cannot create directory `/usr/man': Permission denied
Jun 06 11:01:53 <ant_work> drainbamage: I fear there is smthg to fix wrt i586-linux target
Jun 06 11:01:58 <hrww> mckoan: ping
Jun 06 11:02:41 <hrw> mckoan: http://www.koala.it/it/minipc-2pci.htm says "Side fan 60mm" - please check it cause mine has 50mm ones and now I have 2 spare 60mm fans ;(
Jun 06 11:27:40 <pb_> hi zecke
Jun 06 11:27:45 <woglinde> gm pb
Jun 06 11:27:48 <pb_> hi woglinde
Jun 06 11:37:20 <drainbamage> <ant_work> what i need  to fix wrt i586-linux target
Jun 06 11:37:48 <ant_work> I'm sorry I only cross-compiled forarm
Jun 06 11:37:55 <ant_work> *for arm
Jun 06 11:38:23 <ant_work> btw we use 1.5.22 now, which branch are you building?
Jun 06 11:38:32 <drainbamage> ohk
Jun 06 11:38:34 <drainbamage> 1.5.21
Jun 06 11:38:49 <ant_work> aehm.. I removed 1.5.21 recipe :)
Jun 06 11:39:04 <ant_work> you are on some old/stable branch?
Jun 06 11:39:05 <drainbamage> oh
Jun 06 11:39:11 <drainbamage> yes
Jun 06 11:39:23 <drainbamage> using angstrom
Jun 06 11:40:07 <ant_work> I'll see if there are fixes for building for x86
Jun 06 11:40:14 <drainbamage> ohk
Jun 06 11:40:17 <drainbamage> thnks
Jun 06 11:40:57 <ant_work> pb_: hello, when you'll have time I'd need some light wrt alignments on arm
Jun 06 11:41:58 <ant_work> specifically, I'd need a confirmation I'm looking at the right suspicious function ...
Jun 06 11:45:24 <mlip> wise oe folks help me out ;) anyone knows how a proper .bbappend is written for kernels that do use multi-kernel.inc (I am using oe-core/-meta/-ti); as soon as I include FILESEXTRAPATHS, it crashes on file://configs/* (I did try to create configs dir in my layer too)
Jun 06 12:14:44 <woglinde> hi mickeyl
Jun 06 12:14:46 <woglinde> some news?
Jun 06 12:26:04 <hrw> mickey|office: hello!
Jun 06 12:38:32 <pb_> ant_work: which function is that?
Jun 06 12:41:00 <ant_work> hi pb_ 
Jun 06 12:41:17 <ant_work> I experience a crash and last thing I could see is an alignment trap
Jun 06 12:41:40 <ant_work> binary is statically linked against klibc, so the addresses should be self-contained
Jun 06 12:45:11 <ant_work> pb_: so, let say I have Alignment trap: kexecboot (385) PC=0x0000e17c Instr=0xe5931000 Address=0x401e19bf FSR 0x013
Jun 06 12:45:59 <ant_work> after I recompiled -g I see
Jun 06 12:46:05 <ant_work> (od -S)
Jun 06 12:46:06 <ant_work> e17c:	e1800206 	orr	r0, r0, r6, lsl #4
Jun 06 12:46:24 <ant_work> ^^ is it the right thing to look for?
Jun 06 12:46:35 <pb_> more or less, but you must have changed something else at the same time.
Jun 06 12:46:46 <pb_> try running your recompiled binary and see if you get different addresses when it crashes.
Jun 06 12:47:03 <ant_work> I'm confused wrt .debug binary packaged by oe
Jun 06 12:47:26 <pb_> what is your confusion?
Jun 06 12:47:47 <ant_work> http://paste.debian.net/118857/
Jun 06 12:52:43 <pb_> I'm not quite sure I understand what you are trying to say with that pastebin.
Jun 06 12:53:03 <pb_> what exactly is it that you are confused about?
Jun 06 12:53:24 <ant_work> http://paste.debian.net/118976/
Jun 06 12:53:33 <ant_work> ^^ this is extract from objdump
Jun 06 12:54:10 <ant_work> I'm lead to think the culprit is this e17c:	e1800206 	orr	r0, r0, r6, lsl #4
Jun 06 12:54:43 <pb_> yeah, but that is obviously not correct
Jun 06 12:54:45 <ant_work> but if I look at the previous paste it seem sto me there is another function at that address
Jun 06 12:54:51 <pb_> did you do what I said before?
Jun 06 12:55:07 <ant_work> I can't runi it her
Jun 06 12:55:09 <pb_> which other function does the previous paste have at that address?
Jun 06 12:55:51 <pb_> ah.  well, if you can't run it then there is nothing else to be done.
Jun 06 12:56:28 <pb_> you need to have a matching pair of binary and crash dump, you can't do anything useful with a crash dump that was generated by a different binary to the one you're looking at.
Jun 06 12:57:15 <ant_work> the alignment was originated by the unstripped binary
Jun 06 12:57:34 <pb_> right, but then you recompiled the binary
Jun 06 12:57:47 <ant_work> no, maybe I messed with the logs...
Jun 06 12:58:03 <pb_> didn't you say earlier that you recompiled with -g?
Jun 06 12:58:18 <ant_work> yes, for objdump purposes
Jun 06 12:58:23 <ant_work> then I ran it
Jun 06 12:58:32 <ant_work> and obained the trap
Jun 06 12:58:37 <pb_> ah, I see
Jun 06 12:58:55 <ant_work> I added -g to klibc.bbclass
Jun 06 12:58:55 <pb_> well, you must have mixed something up: that alignment trap message does not correspond to the disassembly you pasted.
Jun 06 12:59:45 <ant_work> fwiw  reproduced teh alignment with another binary, compiled against eglibc/shared
Jun 06 13:00:08 <ant_work> same Instr=0xe5931000
Jun 06 13:04:39 <pb_> okay, so in that case it sounds like it is nothing to do with klibc specifically
Jun 06 13:05:10 <pb_> if you have a matching binary and crash dump for that eglibc binary then you could probably use that one to debug the problem
Jun 06 13:12:09 <ant_work> ok, thx
Jun 06 13:12:19 <ant_work> that supports my idea that RGB code is dangerous
Jun 06 13:12:44 <pb_> well, not necessarily the rgb code
Jun 06 13:13:26 <pb_> your hex2rgb disassembly doesn't contain any instances of the instruction e5931000.
Jun 06 13:13:53 <pb_> so, either it is in a different function, or the binary you are disassembling was built with different enough cflags that the instructions have changed.
Jun 06 13:14:31 <ant_work> wait, I disassembled kexecboot binary, containing hex2rgb and hchar2int
Jun 06 13:15:25 <ant_work> I hav ethe full-file to upload if you have time to look at/grep  it :p
Jun 06 13:15:43 <pb_> well, no, that wouldn't really help
Jun 06 13:15:50 <pb_> as I said, you need a matching pair
Jun 06 13:16:13 <pb_> I could look at the full disassembly, but without a matching crash message it would just be speculation
Jun 06 13:19:48 <ant_work> the issue is this binary is in an initramfs and is failing in a particular case (entering a menu)
Jun 06 13:20:14 <ant_work> happily the binary can be launched from console, that's how I logged the align trap
Jun 06 13:20:52 <ant_work> so, it fails if run as init process, doesn't if launched from shell...
Jun 06 13:21:49 <pb_> I'm a bit confused now.  If it doesn't fail when you run it from the shell, how did you get the alignment trap error?
Jun 06 13:22:07 <ant_work> it just spits align trap instead of freezing :)
Jun 06 13:22:09 <pb_> Or do you mean you're running with alignment traps set to nonfatal, so it prints the message but continues anyway?
Jun 06 13:22:26 <ant_work> yes, continues
Jun 06 13:22:33 <pb_> ah, right, I see
Jun 06 13:22:37 <ant_work> I can even exit it
Jun 06 13:22:41 <ant_work> properly
Jun 06 13:23:47 <ant_work> so I 'guess' this align trap could be fatal inside the initramfs...pure guessing
Jun 06 13:24:14 <pb_> yeah, could be.  what alignment trap setting does your initramfs run with?
Jun 06 13:24:47 <ant_work> good question: standard ones? no shell, no initscripts
Jun 06 13:25:17 <pb_> I guess that'd probably be zero, but you should check sinceit might depend on your kernel
Jun 06 13:25:37 <ant_work> ah, the kernel is very minimalist
Jun 06 13:25:47 <ant_work> no debug, no BUG, no printk...
Jun 06 13:26:33 <ant_work> hm...
Jun 06 13:26:42 <pb_> well, try setting alignment to zero by hand and see if you then get the same behaviour as the initramfs
Jun 06 13:29:03 <ant_work> ah, yes, now I see  /proc/cpu/alignment .. ./proc/sys/debug/alignment . it seems I have to enable debug
Jun 06 13:31:57 <ant_work> pb_: anyway, I suspect those functions modifying RGB... sounds strangely familiar with the 'bad examples' listed in  http://www.aleph1.co.uk/oldsite/armlinux/book/afaq.html
Jun 06 13:32:08 <ant_work> thank you for your time
Jun 06 13:33:08 <mickey|office> hi hrw
Jun 06 13:38:47 <mickey|office> woglinde: news: she's in hospital now, getting contraction stimulii
Jun 06 13:39:10 <pb_> mickey|office: heh, doesn't that mean that you ought to be there as well?
Jun 06 13:39:48 <mickey|office> pb_: i'll join her when the contractions actually start
Jun 06 13:41:13 <pb_> ah, very good
Jun 06 13:43:08 <pb_> my experience of induced labour was that, once it starts, eerything happens rather quickly.
Jun 06 13:45:06 <hrw> pb_: took ~40h for us and ended in cezar's cut (or how it is in proper english)
Jun 06 13:49:00 <drainbamage> trying to buld splashutils in oe
Jun 06 13:49:18 <drainbamage> but getting error during compilation
Jun 06 13:49:43 <drainbamage>  NOTE: make |  cd . && /bin/sh /home/soulfood/thin/build/tmp/work/i586-linux/splashutils-1.5.4.2-r3/splashutils-1.5.4.2/missing --run automake-1.10 --gnu |  cd . && /bin/sh ./config.status Makefile | config.status: creating Makefile | cd . && /bin/sh /home/soulfood/thin/build/tmp/work/i586-linux/splashutils-1.5.4.2-r3/splashutils-1.5.4.2/missing --run autoheader | rm -f stamp-h1 | touch config.h.in | cd . && /bin/sh ./config.status c
Jun 06 14:05:15 <pb_> hrw: "caesarian section"
Jun 06 14:07:37 <hrw> thank you pb
Jun 06 14:12:14 <Crofton> C-section for short
Jun 06 14:19:30 * mwester is very familiar with those  (although not personally, of course)
Jun 06 14:19:38 <kergoth> morning
Jun 06 14:19:44 <mwester> Salutations.
Jun 06 14:19:48 <kergoth> boo for 7am meetings
Jun 06 14:19:58 <mwester> 'specially on Mundays.
Jun 06 14:20:16 <kergoth> indeed
Jun 06 14:21:09 * mwester just noticed that Fedora 15 is released...  so now his build machine is truely waaay out of date.
Jun 06 14:22:13 <mwester> On the other hand, since there are no more updates for Fedora 12, I can safely assume that means that there are NO bugs left in Fedora 12, right?
Jun 06 14:22:22 <celston> Hello all. I'm trying to use an external toolchain on oe-core, I've copied and edited the external-csl-toolchain_2008q3-72.bb recipe, set PREFERRED_PROVIDER variables in local.conf, but now I have conflicting PREFERRED_PROVIDER entries found. Any hints for how to debug such conflicts?
Jun 06 14:23:23 <pb_> g'day kergoth
Jun 06 14:24:08 <kergoth> celston: there's a .inc in conf/ you can include that does most of the work for you, rather than having to mess with the preferred providers yourself
Jun 06 14:26:11 <celston> kergoth: tcmode-external-csl2008q3.inc ?
Jun 06 14:27:14 <kergoth> ah, you're using oe-core? yeah, i'd think you could copy one of those and set TCMODE to the value following the - (external-csl2008q3 in that example)
Jun 06 14:31:46 <celston> kergoth: thanks, I'll have a go.
Jun 06 14:32:05 <kergoth> np
Jun 06 14:34:11 <Tartarus> mickey|office: good luck!
Jun 06 14:44:41 <mckoan> hrw: I don't know
Jun 06 14:46:15 <hrw> mckoan: lesson learnt: do not trust documentation
Jun 06 14:49:39 <CIA-8> 03Mario Schuknecht <schuknecht@dresearch-fe.de> 07org.openembedded.dev * re29b167bc6 10openembedded.git/recipes/linux-libc-headers/ (2 files in 2 dirs): 
Jun 06 14:49:39 <CIA-8> linux-libc-headers-2.6.24: add additional tcp ioctl (for hipox machine only)
Jun 06 14:49:39 <CIA-8> Signed-off-by: Mario Schuknecht <schuknecht@dresearch-fe.de>
Jun 06 14:49:39 <CIA-8> Acked-by: Steffen Sledz <sledz@dresearch-fe.de>
Jun 06 14:51:57 <CIA-8> 03Mario Schuknecht <schuknecht@dresearch-fe.de> 07org.openembedded.dev * r3dfcd3a76e 10openembedded.git/recipes/linux/ (3 files in 2 dirs): 
Jun 06 14:51:57 <CIA-8> linux-2.6.24: optimize flash timings (hipox machine only)
Jun 06 14:51:57 <CIA-8> Signed-off-by: Mario Schuknecht <schuknecht@dresearch-fe.de>
Jun 06 14:51:57 <CIA-8> Acked-by: Steffen Sledz <sledz@dresearch-fe.de>
Jun 06 14:51:57 <CIA-8> 03Thilo Fromm <fromm@dresearch-fe.de> 07org.openembedded.dev * r0caee0e55d 10openembedded.git/recipes/linux/ (2 files in 2 dirs): 
Jun 06 14:51:58 <CIA-8> linux-2.6.24: fix 1/2-byte read access to PCI config space (hipox machine only)
Jun 06 14:51:59 <CIA-8> Signed-off-by: Thilo Fromm <fromm@dresearch-fe.de>
Jun 06 14:51:59 <CIA-8> Acked-by: Steffen Sledz <sledz@dresearch-fe.de>
Jun 06 14:52:00 <CIA-8> 03Thilo Fromm <fromm@dresearch-fe.de> 07org.openembedded.dev * rf04f5a81ac 10openembedded.git/recipes/linux/ (2 files in 2 dirs): 
Jun 06 14:52:00 <CIA-8> linux-2.6.24: add PCI abort handler (hipox machine only)
Jun 06 14:52:12 <CIA-8> Signed-off-by: Thilo Fromm <fromm@dresearch-fe.de>
Jun 06 14:52:12 <CIA-8> 03Steffen Sledz <sledz@dresearch-fe.de> 07org.openembedded.dev * rcc74fd0bc6 10openembedded.git/recipes/linux/ (linux-2.6.24/hipox/defconfig linux_2.6.24.bb): 
Jun 06 14:52:12 <CIA-8> linux-2.6.24: enable some more kernel debug options (hipox machine only)
Jun 06 14:52:12 <CIA-8> Signed-off-by: Steffen Sledz <sledz@dresearch-fe.de>
Jun 06 14:52:12 <CIA-8> 03Thilo Fromm <fromm@dresearch-fe.de> 07org.openembedded.dev * r5164d949a2 10openembedded.git/recipes/linux/ (linux-2.6.24/hipox/defconfig linux_2.6.24.bb): 
Jun 06 14:52:13 <CIA-8> linux-2.6.24: enable some more diagnostic options (hipox machine only)
Jun 06 14:52:14 <CIA-8> * enable process and task accounting
Jun 06 14:52:14 <CIA-8> * enable per-task IO accounting
Jun 06 14:52:15 <CIA-8> Signed-off-by: Thilo Fromm <fromm@dresearch-fe.de>
Jun 06 14:52:15 <CIA-8> 03Steffen Sledz <sledz@dresearch-fe.de> 07org.openembedded.dev * r3b7bb1778b 10openembedded.git/recipes/linux/ (linux-2.6.24/hipox/defconfig linux_2.6.24.bb): 
Jun 06 14:52:29 <CIA-8> linux-2.6.24: disable 2nd SATA port (hipox machine only)
Jun 06 14:52:29 <CIA-8> The 2nd SATA port is not used at hipox machine and causes emission problems
Jun 06 14:52:29 <CIA-8> if activated.
Jun 06 14:52:29 <CIA-8> Signed-off-by: Steffen Sledz <sledz@dresearch-fe.de>
Jun 06 14:55:21 <CIA-8> 03Klaus Kurzmann <mok@fluxnetz.de> 07master * rd719bd5c05 10openembedded.git/recipes/freesmartphone/fsoaudiod_git.bb: 
Jun 06 14:55:21 <CIA-8> fsoaudiod_git.bb: enable cmtspeech plugin
Jun 06 14:55:21 <CIA-8> Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Jun 06 14:55:21 <CIA-8> 03Klaus Kurzmann <mok@fluxnetz.de> 07master * r5c43457a77 10openembedded.git/recipes/freesmartphone/cornucopia.inc: 
Jun 06 14:55:21 <CIA-8> cornucopia.inc: bump FSO_CORNUCOPIA_SRCREV to catch up with newer vala
Jun 06 14:55:22 <CIA-8> Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Jun 06 14:59:23 <CIA-8> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r9298fdc6da 10openembedded.git/recipes/linux/ (4 files in 3 dirs): 
Jun 06 14:59:23 <CIA-8> linux-2.6.39: upgrade to 2.6.39.1 and update shr patch
Jun 06 14:59:24 <CIA-8> * CONFIG_INPUT_LIS302DL is kept disabled, because driver needs to be
Jun 06 14:59:25 <CIA-8> updated to use genirq
Jun 06 14:59:25 <CIA-8> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jun 06 15:00:04 <CIA-8> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r8222e02f5f 10openembedded.git/recipes/freesmartphone/ (7 files): 
Jun 06 15:00:04 <CIA-8> freesmartphone: sync with meta-fso
Jun 06 15:00:04 <CIA-8> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jun 06 15:22:44 <kergoth> gah, screwed up my linux desktop
Jun 06 15:22:48 <kergoth> hrm, maybe not
Jun 06 15:22:50 * kergoth mutters
Jun 06 15:25:32 <pb_> heh
Jun 06 15:25:34 <celston> kergoth: I'm using the tcmode include now, but I get lines like "NOTE: multiple providers are available for virtual/i586-none-linux-gcc (external-poky-toolchain, gcc-cross)". I'm not sure I understand why i586-none-linux- are a dependency now - does this dependency refer to my host compiler?
Jun 06 15:25:49 <pb_> ubuntu keeps asking me if I want to upgrade to 11.04
Jun 06 15:25:57 <pb_> I haven't been brave enough to say yes yet
Jun 06 15:25:58 <kergoth> celston: depends on your MACHINE
Jun 06 15:26:00 <kergoth> pb_: ugh, me too
Jun 06 15:26:03 <kergoth> i tried that once already
Jun 06 15:26:07 <kergoth> my machine stopped booting
Jun 06 15:26:13 * kergoth rolls eyes
Jun 06 15:26:18 <pb_> yeah, one of my coworkers had that experience on his netbook
Jun 06 15:26:40 <celston> my actual arch is x86_64, so I don't know where i586 would come from.
Jun 06 15:26:49 <kergoth> celston: what's your MACHINE?
Jun 06 15:26:55 <pb_> is that your target arch, or your build system arch?
Jun 06 15:27:01 <pb_> i586 sounds like qemux86.conf
Jun 06 15:27:07 <celston> build system arch.
Jun 06 15:27:13 <pb_> ah, well then
Jun 06 15:27:14 <celston> ah
Jun 06 15:27:28 <celston> D'oh.
Jun 06 15:28:25 <celston> I think I assumed it would use uname to find the build arch.
Jun 06 15:29:01 <kergoth> it does
Jun 06 15:29:04 <pb_> yeah, it does
Jun 06 15:29:13 <kergoth> for the third time, what's your MACHINE?
Jun 06 15:29:16 <kergoth> :)
Jun 06 15:29:24 <kergoth> as pb_ says, i586 sounds like qemux86
Jun 06 15:29:38 <celston> Sorry, it *was* MACHINE ??= "qemux86" I just changed it to MACHINE ?= "qemux86-64"
Jun 06 15:30:39 <celston> MACHINE refers to build or target arch?
Jun 06 15:30:51 <pb_> target
Jun 06 15:31:26 <kergoth> erm, you should really read the wiki or user manual some if you don't know what machine is, it's one of the two most important variables in oe :)
Jun 06 15:34:01 <pb_> hm, we don't seem to have had any tsc meeting minutes for a while.  did they change their schedule?
Jun 06 15:34:20 <kergoth> hmm, good question
Jun 06 15:34:38 <pb_> the last set I can find in the archive is may 5
Jun 06 15:35:35 <pb_> maybe you could ask tom if you happen to be speaking to him.
Jun 06 15:35:59 <oe-rookie> hi, I have a question: I'm building a eglibc based distro but I'd like busybox to be statically compiled against uclibc. How can I deal with that? Thanks in advance.
Jun 06 15:35:59 <kergoth> Tartarus: ping
Jun 06 15:36:17 <Tartarus> kergoth: pong
Jun 06 15:36:19 <mwester> khem,  clean build of the slugos layers stuff fails building pseudo -- looks like a path issue (searching host libs for gcc_s library) -- is this an openembedded-core issue, or something in the slugos layers?  I just need to be pointed in the right direction - thanks!  http://pastebin.com/p0nb5JfK
Jun 06 15:36:21 <kergoth> Tartarus: /me points above
Jun 06 15:36:36 <Tartarus> pb_: bah
Jun 06 15:36:47 <pb_> oe-rookie: with difficulty.  you can't really mix uclibc and eglibc in a single distro, at least not easily
Jun 06 15:37:08 <pb_> you could create a variant uclibc package which stages itself into a special prefix, and then a variant busybox that builds against it.
Jun 06 15:37:14 <Tartarus> We've been meeting, Jefro's been taking minutes, will see what's the hold up
Jun 06 15:37:17 <pb_> not exactly pretty, but I think that's about your only option
Jun 06 15:37:45 <pb_> unless you want to have two separate distros, one for the uclibc components and one for the eglibc components, and then a postprocessing mashup step to put them together
Jun 06 15:37:53 <oe-rookie> pb_: thanks. I thought it would not be easy....
Jun 06 15:38:09 <pb_> Tartarus: okay, cool, thanks
Jun 06 15:41:49 <pb_> kergoth: btw, could you update my authorized keys in gitosis if you have a spare moment?
Jun 06 15:42:11 <Jay7> evening
Jun 06 15:42:32 <pb_> the only one that's there right now is for my work account at my old job.  I guess that one can be removed.
Jun 06 15:43:27 <Jay7> pb_: about your talk with ant_work
Jun 06 15:43:41 <Jay7> initramfs version is running kexecboot as init
Jun 06 15:43:50 <pb_> yeah, so I gathered from ant
Jun 06 15:43:57 <Jay7> so freeze is easy to understand then
Jun 06 15:44:06 <pb_> well, yes and no
Jun 06 15:44:16 <Jay7> someting like 'panic: attempting to kill init'
Jun 06 15:44:22 <pb_> it's easy to understand why it would freeze if init crashes
Jun 06 15:44:34 <pb_> but it is not obvious why init is crashing in the first place, if it doesn't crash when he runs the same binary from the shell
Jun 06 15:44:59 <Jay7> btw, this happens only on collie/poodle iirc
Jun 06 15:45:16 <Jay7> we haven't seen that on pxa270 machines
Jun 06 15:45:40 <Jay7> well... anyway I know some places that may produce that trap..
Jun 06 15:45:57 <Jay7> just need some time and luck to find
Jun 06 15:46:15 <kergoth> pb_: yeah, sure
Jun 06 15:46:34 <pb_> kergoth: if you could copy the ones from my ~/.ssh/authorized_keys on melo into gitosis, that'd be great
Jun 06 15:46:57 <kergoth> hrm, not sure if i have ssh access to melo :)
Jun 06 15:47:09 <pb_> ah, heh
Jun 06 15:47:09 <kergoth> i have git admin access, that's about it, i think
Jun 06 15:47:25 <pb_> okay, let me mail you the keys
Jun 06 15:48:55 <kergoth> k
Jun 06 15:49:20 <pb_> btw, as far as I can tell you do have shell access on melo
Jun 06 15:49:22 <pb_> :-}
Jun 06 15:49:33 <pb_> keys sent, anyway
Jun 06 15:51:10 <pb_> Jay7: yeah, as I said to ant, if he can capture a crash dump and a matching binary then it should be easy to find out what is wrong.  without those two things all you can really do is speculate, which is probably a waste of time.
Jun 06 15:52:02 <Jay7> pb_: problem is to get crash dump from binary with debugging symbols :)
Jun 06 15:52:10 <kergoth> huh
Jun 06 15:52:26 <pb_> Jay7: why is that a problem?
Jun 06 15:52:31 <Jay7> I'm a bit lost in cross-debugging and OE dbg packages
Jun 06 15:52:36 <kergoth> well, i get denied for kergoth@melo, publickey, so if i have an account, i can't ssh into it :)
Jun 06 15:52:44 <pb_> oh, hm
Jun 06 15:55:25 <pb_> jay7: well, you shouldn't need to get involved with cross-debugging or -dbg packages.  just build a binary with symbols in, run it and profit.
Jun 06 15:55:41 <pb_> jay7: it doesn't even need to be -g, you just need one that isn't stripped
Jun 06 15:56:13 <pb_> having -g would be a bonus, but not absolutely required
Jun 06 15:56:42 <Jay7> pb_: how to say OE to not strip my binary? :)
Jun 06 15:56:54 <Jay7> It's kexecboot recipe
Jun 06 15:57:29 <pb_> INHIBIT_PACKAGE_STRIP, or just fish it out of the build directory by hand
Jun 06 15:57:52 <pb_> it only strips the installed copy, not the one in ${S}
Jun 06 15:58:40 <kergoth> I think you may want PACKAGE_STRIP = "no", i don't think the other is still used nowadays
Jun 06 15:58:45 <pb_> oh, right
Jun 06 15:59:10 <Jay7> nice, thanks 
Jun 06 15:59:21 <Jay7> I'll try this evening (I hope) :)
Jun 06 16:00:12 <pb_> kergoth: oe-core still seems to use INHIBIT_PACKAGE_STRIP
Jun 06 16:00:32 <pb_> but you're right, seems to be PACKAGE_STRIP in oe
Jun 06 16:00:36 <Jay7> I'm still using 'classic' OE now
Jun 06 16:00:42 <kergoth> huh, didn't notice that
Jun 06 16:00:50 <pb_> either way, the respective local.conf.samples describe the right variable to set
Jun 06 16:00:50 <kergoth> we really need to get the classes synced
Jun 06 16:00:55 <kergoth> cool
Jun 06 16:01:13 <pb_> yeah, it is a bit sad that oe-core is three years out of date in quite a few places
Jun 06 16:03:57 <celston> kergoth pb_ : thanks for the help, compiling with the external toolchain now (I think...)
Jun 06 16:04:05 <pb_> very good
Jun 06 16:04:11 <kergoth> nice
Jun 06 16:06:33 <celston> There may be trouble ahead, because I've blindly adding missing deps that I thought probably should come out of the external tc package to the PROVIDES/RPROVIDES list. Might have to edit the tc recipe package file lists to ensure they do get copied.
Jun 06 16:06:57 <celston> (in this case glibc and linux-libc-headers-dev)
Jun 06 16:07:08 <celston> and virtual/mips-none-linux-libc-initial 
Jun 06 16:07:48 <pb_> I wouldn't have expected anything to depend on *-libc-initial in the external toolchain case.  That package is only needed for toolchain bootstrap.
Jun 06 16:08:08 <pb_> so, if you're having to provide it, it suggests there might be some other bug elsewhere in the metadata
Jun 06 16:08:35 <celston> ah, the external tc recipe I copied had virtual/mips-none-linux-gcc-initial in the provides, could that be the cause?
Jun 06 16:09:06 <celston> Is there a summary anywhere of what each of the core virtual packages are expected to contain (broadly) ?
Jun 06 16:09:20 <pb_> good question.  not that I know of.
Jun 06 16:09:36 <pb_> it is a shame the wiki is broken, otherwise this would be a good thing to put there.
Jun 06 16:10:42 <celston> If it starts working again then I'd be happy to draft a section on using an external toolchain.
Jun 06 16:17:54 <ant_work> Jay7: on poodle for sure. I can't say on collie...well, ithas same rotated qvga layout but different processor (I vaguely remind strongarm shouldn't have alignments issues)
Jun 06 16:18:30 <ant_work> on pxa25x I've seen many, instead
Jun 06 16:18:37 <ant_work> :p
Jun 06 16:18:58 <Jay7> ant_work: I'm rewriting some code of xpm parsing and image handling
Jun 06 16:19:11 <Jay7> it may help or may break it more :)
Jun 06 16:19:18 <ant_work> maybe you've hit some obscure bug...
Jun 06 16:20:27 <Jay7> pb_: btw, is it safe to use struct * -> void * -> struct * conversion?
Jun 06 16:20:42 <Jay7> no operation is made when it is void *
Jun 06 16:20:42 <pb_> depends what you mean by "safe"
Jun 06 16:20:58 <anarsoul> Jay7: yep, it's safe
Jun 06 16:20:59 <Jay7> I'm just using void pointer so attach icons to menu
Jun 06 16:21:07 <Jay7> pointer to icon even
Jun 06 16:21:34 <pb_> it's safe in the sense that it is allowed by the C standard and the compiler will do what you expect with it.
Jun 06 16:21:37 <ant_work> have you compared to the 'bad examples' ?
Jun 06 16:21:56 <pb_> it's unsafe in the sense that, obviously, you are throwing away type checking and it is easy to screw it up and introduce bizarre bugs
Jun 06 16:22:44 <pb_> but essentially yes, that is basically what void* is for.
Jun 06 16:23:04 <Jay7> ant_work: yes...  but I can't find place by eyes.. need crashdump
Jun 06 16:24:07 <Jay7> now I have other suspicious code - packing rgba into uint32_t
Jun 06 16:24:19 <Jay7> and unpacking it later
Jun 06 16:24:32 <Jay7> using binary logic and shifting
Jun 06 16:25:10 <Tartarus> pb_: ok, Jefro is confused as to why minutes past may 5th haven't been seen 'cuz he's posted, and is looking into it.  Or that's how I read his string of expletive masked :)
Jun 06 16:25:15 <celston> mmmmm, bitshifting.
Jun 06 16:26:53 <ant_work> Jay7: I feel we are in the exact case of structures contained in other structures..
Jun 06 16:27:03 <Jay7> http://goo.gl/Qs6Do is used to pack and http://goo.gl/xVPtG is used to unpack
Jun 06 16:27:15 <Jay7> well.. now it 'was used'
Jun 06 16:27:31 <Jay7> I've changed today this part to respect alpha-channel
Jun 06 16:28:34 <pb_> Tartarus: heh, very good.  thanks for that.
Jun 06 16:30:21 <ant_work> pb_: I see you're listed ...I feel this bookshould not be online...
Jun 06 16:30:37 <pb_> jay7: that's fine, there's nothing wrong with either of those code fragments in themselves.
Jun 06 16:31:04 <ant_work> ARMLinux for Developers 
Jun 06 16:31:39 <Jay7> pb_: thanks :)
Jun 06 16:32:31 <ant_work> Jay7: ofc we have to enable some sort of kernel debug to see it crash ...
Jun 06 16:32:33 <pb_> the hex2rgb one might be a bit dubious depending on how exactly it is used
Jun 06 16:32:51 <pb_> the function is fine, but some of its callers might perhaps not be.  you'd need to check.
Jun 06 16:44:11 <ant_work> Jay
Jun 06 16:44:46 <ant_work> Jay7: hm.. we use 6 bytes hex values for xpm icons
Jun 06 16:45:13 <ant_work> why does it enter e17c:?
Jun 06 16:45:24 <ant_work> is the case 12+1 (apparently)
Jun 06 16:50:33 <Jay7> ant_work: 12+1 is not used now
Jun 06 16:51:03 <Jay7> all xpm icons I ever seen was using 6 char hex color #abcdef
Jun 06 16:51:19 <Jay7> well, anyway now it's kind of offtopic here :)
Jun 06 17:03:25 <otavio> Hello
Jun 06 18:21:48 <woglinde> hi stefan
Jun 06 18:23:10 <tzanger> hm, is this the right place to ask a question about a build failure in arago? under ubuntu 10.04 there aren't any issues, but with 10.10 I get a build error in util-linux-ng-native 2.17 "no rule to make target .deps/uuid_time.Plo"
Jun 06 18:23:14 <stefan_schmidt> hi woglinde 
Jun 06 18:23:18 <stefan_schmidt> hi all
Jun 06 18:24:21 <woglinde> tzanger topic
Jun 06 18:25:38 <tzanger> woglinde: ok, not a distro support channel I do understand that... but #ubuntu is unlikely to know anything about OE
Jun 06 18:25:53 <tzanger> I"m unsure that this is a distro support question at all
Jun 06 18:26:02 <mdp> tzanger, #arago?
Jun 06 18:26:10 <denix> try #arago
Jun 06 18:26:24 <woglinde> tzanger problem is in oe we have now newer util-linux soft
Jun 06 18:26:25 <tzanger> hmm, okay.  I've never used it before, didn't know that there was a separate channel for it :-)
Jun 06 18:26:35 <tzanger> I was always using angstrom before
Jun 06 18:26:36 <woglinde> and to be honest I didnt see this error so far
Jun 06 18:26:52 <tzanger> ok, I appreciate the pointer to the other chan 
Jun 06 18:40:39 <GNUtoo> tzanger, distro means target distro
Jun 06 18:40:51 <tzanger> GNUtoo: ahh.
Jun 06 18:41:06 <tzanger> so would this chan be suitable for "baseline" OE then and not offshots?
Jun 06 18:41:07 <tzanger> er shoots
Jun 06 18:41:30 <GNUtoo> how could we help if we don't know forks
Jun 06 18:41:45 <GNUtoo> someone pointed yo to the fork's channel tough
Jun 06 18:41:55 <tzanger> yes, and I thanked him. :-)
Jun 06 18:42:04 <tzanger> I am still getting a handle on what is what when it comes to OE
Jun 06 19:53:26 <otavio> khem: hello ... 
Jun 06 19:53:41 <otavio> khem: I got most of chicken toolchain working and it builds fine  for most eggs 
Jun 06 19:53:48 <otavio> khem: but I got a case it fails
Jun 06 19:54:18 <otavio> khem: basically when it calls the toolchain, in case it has the native one available it is preferred against the cross one
Jun 06 19:57:48 <otavio> khem: any idea why this is happening? And how to workaround/fix it?
Jun 06 19:58:03 <otavio> khem: I know it is path related ... but do you have any clue about why?
Jun 06 20:46:10 <otavio> Anyone has a clue about the toolchain issue I spotted above?
Jun 06 21:37:24 <CIA-8> 03Paul Eggleton <paul.eggleton@linux.intel.com> 07master * r11714efa60 10openembedded.git/recipes/opie-ttf-support/opie-ttf-support_1.1.bb: 
Jun 06 21:37:24 <CIA-8> opie-ttf-support: add LICENSE field
Jun 06 21:37:24 <CIA-8> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Jun 06 21:56:03 <sr105> If I want to make a change to one file in a recipe's "files" directory without making changes inside the git tree, do I have to copy the recipe and all of the "files" tree for that recipe into my BBPATH override area? 
Jun 06 22:09:02 <Tartarus> no
Jun 06 22:09:23 <Tartarus> If you want to change, say, recipes/busybox/busybox-1.18.4/defconfig you can just duplicate that
Jun 06 22:09:43 <Tartarus> And if you want to modify busybox_1.18.4.bb you can probably just do what you want in busybox_1.18.4.bbappend in your override area
Jun 06 22:10:00 <fray> e300 or 440 would be my personal preference right now
Jun 06 22:10:16 <fray> however, I just need something 603e or "better" for LSB compatibility testing
Jun 06 22:41:54 <sr105> Tartarus: thanks
Jun 06 22:42:33 <sr105> Tartarus: I'm modifying files/scripts/mount.sh in udev. If I just put that file in my override area, it doesn't get picked up.
Jun 06 22:43:10 <Tartarus> recipes/udev/udev/mount.sh you mean?
Jun 06 22:43:13 <sr105> Tartarus: Maybe I'll need to take a look at the udev recipe. Thanks for the general knowledge.
Jun 06 22:43:18 <sr105> no
Jun 06 22:43:18 <Tartarus> And where did you place your new version
Jun 06 22:43:27 <sr105> recipes/udev/files/scripts/mount.sh
Jun 06 22:43:39 * Tartarus has no recipes/files/
Jun 06 22:43:43 <Tartarus> er, recipes/udev/files
Jun 06 22:43:54 <sr105> in another tree that only includes my files and comes first in BBPATH
Jun 06 22:44:06 <sr105> mine does (It's not the latest OE tree)
Jun 06 22:44:21 <Tartarus> k
Jun 06 22:44:22 <sr105> and git says it is unmodified
Jun 06 22:44:34 <Tartarus> Well, you can override it, you'll just have to make sure you put it in the right place
Jun 06 22:44:47 <Tartarus> local/recipes/udev/files/scripts/mount.sh should cover it
Jun 06 22:44:58 <sr105> so, I should be able to override a single file like that
Jun 06 22:45:01 <Tartarus> otherwise bitbake -e udev and look at the various FILES*PATH variables
Jun 06 22:45:33 <Tartarus> yes, the example I gave above is from our local collection
Jun 06 22:50:51 <kergoth> sr105: BBPATH isn't how either recipes or file:// files are found.
Jun 06 22:51:30 <sr105> kergoth: I thought BBPATH was used to find classes, conf, and recipes
Jun 06 22:52:36 <sr105> From the manual: "BitBake classes … are located in classes/ relative to the dirs in BBPATH."
Jun 06 23:01:07 <sr105> Tartarus: It seems that FILESPATH includes several paths in my oe tree under recipes/udev, but no paths under local
Jun 06 23:01:29 <Tartarus> Then your local.conf isn't pulling in your local overrides collection
Jun 06 23:02:03 <fray> in the current oe-core ./scripts/create-pull-request there is a slight issue..  there is no documentation on how to configure the remote url.. :P
Jun 06 23:02:16 <Tartarus> sr105: Maybe you need something like this:
Jun 06 23:02:18 <Tartarus> FILESPATHBASE = "${@':'.join(os.path.join(collection, 'recipes', os.path.basename('${FILE_DIRNAME}')) for collection in '${COLLECTIONS}'.split())}"
Jun 06 23:02:45 <Tartarus> and COLLECTIONS has your local stuff in it, in local.conf
Jun 06 23:03:01 <Tartarus> and openembedded
Jun 06 23:04:51 <sr105> I was given this oe tree from another. Is that line common in local.conf? I'm wondering if the previous owners broke something
Jun 06 23:06:06 <sr105> yes, I see local.conf.sample and mine deviates quite a bit
Jun 06 23:06:29 <kergoth> sr105: config files and classes, yes. the documentation doesn't say recipes are found via bbpath, as they aren't
Jun 06 23:07:03 <sr105> kergoth: thanks, I didn't know that
Jun 06 23:14:51 <sr105> does the ordering in BBFILES matter? first has priority?
Jun 06 23:19:00 <sr105> I found that setting finally in my site.conf:  http://pastebin.com/P3E9cJb9
Jun 06 23:19:25 <sr105> They seem to list the oe tree first and then set some sort of priorities later
Jun 06 23:27:04 <khem> sr105: for BBFILES priority is used
Jun 06 23:27:17 <khem> order of specifying them does not matter
Jun 06 23:27:30 <khem> for BBPATH however the order matters
Jun 06 23:27:56 <sr105> understood
Jun 06 23:29:01 <sr105> I'm thinking my potential solution may be related to the snippet that Tartarus posted
Jun 06 23:29:28 <sr105> however, if I try to use that line, I get errors about it.
Jun 06 23:34:16 <Tartarus> Yeah, you need to have a chat with whoever gave you that tree
Jun 06 23:34:24 <sr105> http://pastebin.com/eNBpFAAj
Jun 06 23:34:24 <sr105> I see this in my -e output. 
Jun 06 23:34:27 <Tartarus> It's not stock and they need to explain how it's intended to be used
Jun 06 23:38:52 <sr105> Is COLLECTIONS supposed to be set by the user? I only see it in the stock collections.inc
Jun 06 23:48:28 <Tartarus> yes
Jun 06 23:48:40 <Tartarus> with full paths or variables that get expanded
Jun 06 23:58:22 <ka6sox-away> I'm going to break the OE wiki for a  little bit as I add a cache to it.
Jun 07 00:00:03 <sr105> Tartarus: Thanks, I set COLLECTIONS followed by your FILESPATHBASE and it worked.
Jun 07 00:03:39 <Tartarus> np
Jun 07 00:04:35 <sr105> That was the last piece I needed to remove all of the my predecessor's modifications to the oe tree.
Jun 07 00:57:25 <CIA-8> 03Paul Eggleton <paul.eggleton@linux.intel.com> 07master * rec9c3a637e 10openembedded.git/recipes/h2200-bootloader/h2200-bootloader.bb: 
Jun 07 00:57:25 <CIA-8> h2200-bootloader: add LICENSE field
Jun 07 00:57:25 <CIA-8> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Jun 07 01:06:06 <ka6sox-farfarawa> are the mirrors staying up to date?
Jun 07 01:06:37 <ka6sox-farfarawa> because I'm still dying every 0600-0800 with european devs pulling from the oe master.
Jun 07 01:06:52 <ka6sox-farfarawa> instead of the mirrors.
Jun 07 01:07:49 <ka6sox-farfarawa> the master should be for pulling/pushing changes.
Jun 07 01:47:29 <Tartarus> Do we publicize a mirror?
Jun 07 01:51:02 <Tartarus> Jefro: hey, now that you're an OE eV member, you can post tsc minutes to openembedded-members yourself :)
Jun 07 01:51:15 <Tartarus> koen had been forwarding them there
Jun 07 01:51:37 <Crofton> :)
Jun 07 01:51:45 <Crofton> need to make sure they get added t the list 
**** ENDING LOGGING AT Tue Jun 07 02:59:57 2011