**** BEGIN LOGGING AT Tue Dec 20 02:59:57 2011
Dec 20 07:20:59 <d4ny> Hmm, there seems to be some issues with having bash at a non-standard location on the build machine. meta-toolchain, do_populate_sdk fails with "/usr/bin/bash is needed by eglibc-utils-2.13-r15+svnr14157.ppce500mc". And bash seems to be located in sysroot as it should at /bin/bash. Anyone got a hint at where this error eminates from ?
Dec 20 10:12:06 <ollebull> Can
Dec 20 10:12:11 <ollebull> oops
Dec 20 10:14:46 <ollebull> opkg is complaining about not beeing able to create its lock file in /var/lib/opkg... This directory seem to be missing in my setup and haven't been able to figure out what's missing. What is needed more than the package "opkg" to get it up running at target?
Dec 20 10:15:58 <ollebull> Might be related, don't know: http://permalink.gmane.org/gmane.linux.embedded.poky/6489
Dec 20 10:16:41 <ollebull> ...though adding "package-managment" to the IMAGE_FEATURES list doesn't seem to fix it for me
Dec 20 12:46:56 <ALarabi> hello
Dec 20 12:48:44 <SUJ> Hi
Dec 20 12:52:53 <otavio> sgw1: around?
Dec 20 13:01:26 <otavio> dongxiao: hi
Dec 20 13:01:34 <otavio> dongxiao: did you get my reply on ml?
Dec 20 13:02:21 <SUJ> otavio: I need networks arabic
Dec 20 13:03:19 <otavio> ??
Dec 20 13:04:08 <SUJ> on the irc
Dec 20 15:07:13 <sgw1> otavio: ping
Dec 20 15:07:47 <otavio> sgw1: I am starting working on udev changes
Dec 20 15:08:20 <otavio> sgw1: https://github.com/OSSystems/oe-core/compare/ae4118a1f78f113c3d687c3aa6a86007cf977cae...master
Dec 20 15:09:52 <otavio> sgw1: still doing it in small steps
Dec 20 15:10:10 <otavio> sgw1: in fact I am backporting the changes to 164 first to later just update it to 173
Dec 20 15:25:48 <sgw1> otavio: good morning, I have been on the phone, so slow to respond, maybe you should also coordinate with incandcent (Joshua)
Dec 20 15:50:19 <otavio> sgw1: yes
Dec 20 15:50:29 <otavio> sgw1: i read his mail after i started doing it
Dec 20 16:04:58 <sgw1> otavio: would you like to join the tech call this morning?
Dec 20 16:06:44 <sgw> incandescant: you should talk with otavio, as he is also working on udev sync
Dec 20 16:07:59 <incandescant> sgw: otavio: great! I've not spent a huge amount of time on it yet so can hold off on otavio's patches
Dec 20 16:08:47 <sgw> incandescant: you mean hold off on your patch work, in favor of otavio's patches, correct?
Dec 20 16:09:13 <otavio> sgw: tech call, sure
Dec 20 16:09:31 <sgw> Participant passcode:   49611427
Dec 20 16:09:31 <sgw> Dial-in number:         1.972.995.7777
Dec 20 16:09:32 <sgw> US Toll Free number:    1.877.561.6828
Dec 20 16:09:35 <otavio> incandescant: I'd love to have someone looking after me to see if I did something stupid
Dec 20 16:10:05 <incandescant> otavio: I'll be happy to take a look, I'm not especially familiar with udev (which was part of the reason I wanted to look :-))
Dec 20 16:10:21 <otavio> sgw: I am not sure I will be able to follow people talking too fast
Dec 20 16:10:41 <sgw> otavio: it's up to you.
Dec 20 16:11:22 <otavio> incandescant: 13:03] < otavio> sgw1: https://github.com/OSSystems/oe-core/compare/ae4118a1f78f113c3d687c3aa6a86007cf977cae...master
Dec 20 16:42:06 <otavio> incandescant: i am porting changes from meta-oe to oe-core
Dec 20 16:42:23 <otavio> incandescant: in the end I plan to have meta-oe using the inc file
Dec 20 16:43:20 <incandescant> otavio: that's exactly what I'd like to see, the changes so far look good to me - I'll be happy to test when you've got a complete series
Dec 20 16:44:07 <otavio> incandescant: I will check if there's anything on meta-oe to be done, besides the version update
Dec 20 16:44:14 <otavio> incandescant: and ask you for a test
Dec 20 16:44:32 <otavio> incandescant: so we do the version change later
Dec 20 16:44:55 <incandescant> otavio: sounds good
Dec 20 18:11:37 <kergoth> Hmm, anyone care if I submit a patch or 3 to add some variable type flags?
Dec 20 18:45:31 <zeddii> kergoth: around ?
Dec 20 18:46:26 <zeddii> when you are around, I was trying to apply your patch abstraction to my tree here, and I can't get a version that isn't corrupted, not even from patchwork.
Dec 20 19:08:24 <kergoth> hmmm, odd
Dec 20 19:08:31 * kergoth investigates
Dec 20 19:08:44 <zeddii> I'm manually reconstructing it now, only a corrupt line 116 now :)
Dec 20 19:09:06 <kergoth> I wonder if thunderbird accidentally wrapped it or something
Dec 20 19:09:09 * kergoth scratches head
Dec 20 19:10:31 <zeddii> broken long lines, etc. looks like it.
Dec 20 19:11:40 <otavio> sgw: sent the first patchset related to udev
Dec 20 19:11:47 <otavio> sgw: please give it a good test
Dec 20 19:13:46 <kergoth> bah, dangit, sorry about that, I'll see about resending. for some reason send-email doesn't work on this box, only option is to imap-send to gmail and send it from drafts.. gmail's web interface likes to corrupt patches though.. will have to see how to configure tbird to stop doing it
Dec 20 20:11:54 <khem> kergoth: you can configure send-mail to use gmails imap interface
Dec 20 20:12:22 <khem> [sendemail] smtpencryption = tls smtpserver = "smtp.gmail.com" smtpserverport = 587
Dec 20 20:12:46 <khem> smtpuser = "abc@gmail.com"
Dec 20 20:12:56 <khem> smtpssl = true
Dec 20 20:13:04 <khem> smtppass = "xxxxx"
Dec 20 21:31:28 <zenlinux> Can anyone tell me why a recipe would specify the LEAD_SONAME in it? Presumably their library build system isn't naming things correctly?
Dec 20 21:32:04 <zenlinux> (I'm looking at libevent fwiw - and am in the process of upgrading it)
Dec 20 21:37:22 <incandescant> zenlinux: I think it's so the debian renaming knows what libname to use
Dec 20 21:37:58 <incandescant> zenlinux: see debian.bbclass
Dec 20 21:38:15 <zenlinux> incandescant, thanks
Dec 20 21:40:52 <incandescant> np
Dec 20 21:42:19 <kergoth> khem, yeah, that's what I use. but on that box it fails inexplicably
Dec 20 21:42:22 <kergoth> :\
Dec 20 22:02:38 <khem> zenlinux: debian needs a shared library name to rename the package
Dec 20 22:02:54 <khem> kergoth: thats strange
Dec 20 22:03:04 <khem> kergoth: if webclient works on same box
Dec 20 22:06:43 <zenlinux> khem, incandescant - what still strikes me as confusing is why setting LEAD_SONAME isn't necessary in most recipes? I'm trying to figure out if this variable is still needed in the upgraded recipe version, and am not sure what to check for to see if this is the case.
Dec 20 22:07:19 <kergoth> LEAD_SONAME is used to control the behavior regarding the rename of packages based on library soname. if there's only one library in the package, it doesn't need to be explicitly told what name to use..
Dec 20 22:07:21 <khem> if you have more than one .so going into packages
Dec 20 22:07:21 <kergoth> afaik, anyway
Dec 20 22:07:41 <khem> thats right
Dec 20 22:08:49 <zenlinux> thanks for that explanation, I can see this is the case still for the upgraded version
Dec 20 22:52:20 <kishore> Hi,
Dec 20 22:52:30 <kishore> I get ERROR: Function 'Unpack failure for URL: 'http://tango.freedesktop.org/releases/icon-naming-utils-0.8.7.tar.gz for edison branch
Dec 20 22:52:44 <kishore> any idea what went wrong?
Dec 20 22:53:27 <kergoth> you'll need lto look at the log
Dec 20 22:53:35 <kishore> Log data follows: | NOTE: Unpacking /usr/local/src/yocto/edison/build/downloads/icon-naming-utils-0.8.7.tar.gz to /usr/local/src/yocto/edison/build/tmp/work/x86_64-linux/icon-naming-utils-native-0.8.7-r3/ |  | gzip: stdin: not in gzip format | tar: Child returned status 1 | tar: Error is not recoverable: exiting now
Dec 20 22:53:49 <kishore> This is the log
Dec 20 22:54:05 <kergoth> it tells you the problem, the file isn't a gzip file. the most common cause of that sort of thing is usually upstream replacing a file with an html file
Dec 20 22:55:44 <kishore> yeah, the link is broken.
Dec 20 22:55:56 <kishore> how do we fix this problem?
**** ENDING LOGGING AT Wed Dec 21 02:59:56 2011