**** BEGIN LOGGING AT Wed May 26 02:59:57 2010
May 26 02:59:58 <khem`> Package: module-init-tools-depmod
May 26 03:00:04 <khem`> thats what control file contains
May 26 03:00:16 <kergoth> no, the control file of udev
May 26 03:00:21 <kergoth> make sure it really does depend on depmod
May 26 03:00:36 <kergoth> if you set RDEPENDS but RDEPENDS_${PN} exists, the latter will override the fomer.
May 26 03:00:37 <kergoth> former
May 26 03:00:45 <kergoth> you sould be setting RDEPENDS_${PN} anyway
May 26 03:00:52 <kergoth> so i'd suggest doing that first before anything else
May 26 03:00:56 <khem`> its not there in depends
May 26 03:01:10 <khem`> depends: update-rc.d, libc6, libacl1, libglib-2.0-0, libusb-0.1-4
May 26 03:01:17 <khem`> ah
May 26 03:01:20 <khem`> lemme try that
May 26 03:01:53 <kergoth> might want to do += on it too, just to be safe
May 26 03:02:01 <kergoth> in case it already has stuff in it
May 26 03:02:45 <khem`> hmm yes right
May 26 03:03:30 <khem`> kergoth: is += preferred over _append ?
May 26 03:03:44 <kergoth> only use _prepend/_append if you have to, imo
May 26 03:03:58 <kergoth> +=/=+ is immediate, the others are postponed until the end of the parse
May 26 03:04:11 <kergoth> _prepend/_append is useful in classes to make sure a dep shows up no matter what a recipe writer does
May 26 03:04:14 <kergoth> but beyond that, i'd avoid it
May 26 03:04:46 <khem`> right
May 26 03:05:06 <khem`> ${PN} did the trick
May 26 03:05:55 <kergoth> great
May 26 03:06:14 <khem`> ok that works now
May 26 03:06:17 <kergoth> (aside: recipe_sanity warns about that.  INHERIT += recipe_sanity, bitbake -c recipe_sanity foo, or -c recipe_sanity_all)
May 26 03:06:23 <khem`> I am having issues with shadow 
May 26 03:06:43 <khem`> which is not letting me root login on console no matter what I try
May 26 03:06:51 * kergoth hasn't deal with shadow much recently
May 26 03:07:08 <khem`> busybox/tinylogin works well
May 26 03:07:38 <khem`> what confuses more is that it worked on osk5912 board but same does not work on qemuarm
May 26 03:07:51 <khem`> both are armv5te 
May 26 03:08:29 <kergoth> that's really strange
May 26 03:08:43 * khem` has recipe_sanity in INHERIT in local.conf
May 26 03:09:01 <khem`> yeah qemu being my workhorse I am trying to fix it
May 26 03:09:13 <kergoth> maybe the inherit should automatically pull in the _all via do_build
May 26 03:10:00 <kergoth> i have a sheevaplug i finally hooked up, was planning on using it to test oe with, but now i think i might use it as a torrent server instead... so now i need something else to test with.  beagleboard the way to go nowadays for a cheap board to test oe on, or should i buy a second plug?
May 26 03:10:05 <kergoth> guess it depends
May 26 03:10:07 * kergoth ponders
May 26 03:10:28 * kergoth hasn't done much with the actual OE distros, rather than just build stuff, in some time
May 26 03:10:35 <kergoth> getting rusty
May 26 03:11:01 <khem`> kergoth: you should
May 26 03:11:35 <khem`> kergoth: beagle is nice
May 26 03:12:03 <kergoth> don't need much connectivity other than usb and the like, i'm not exactly a hardware guy :)
May 26 03:12:20 <kergoth> course, if there's ready to go addon boards and the like, could probably manage that
May 26 03:27:14 <CIA-1> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r523f22b938 10openembedded.git/recipes/udev/ (9 files): (log message trimmed)
May 26 03:27:14 <CIA-1> udev: Use udev.inc and add udevadm to udev pacakge instead of udev-utils
May 26 03:27:14 <CIA-1> * Main purpose of the patch was to fix the problem where udev-utils was
May 26 03:27:14 <CIA-1> needed to be in root file system just to get udevadm binary. So this
May 26 03:27:14 <CIA-1> binary is moved into udev package instead.
May 26 03:27:15 <CIA-1> * Use INC_PR for all except udev 151.
May 26 03:27:16 <CIA-1> * Use udev.inc in all recipes except udev 151.
May 26 06:24:10 <eFfeM_work> denix, saw your msg, actually http://docs.openembedded.org/usermanual/html/commonuse_prebuilt_toolchain.html seems to be fairly outdated, I made progress by not defining CC, CXX etc etc, from external-toolchain.inc etc I understand there is a better way, but can't really find a good description on how to add my own external toolchain (gcc for nios2)
May 26 06:25:59 <janp> eFfeM_work: removing the trailing slash worked, it builds fine now. Thanks for all the help.
May 26 06:26:51 <eFfeM_work> janp, np, my pleasure (i've been bitten by this too, actually perhaps the sanity checker should detect this, not really an idea how to add that though, my python is too limited to do that)
May 26 06:27:51 <eFfeM_work> RP, kergoth, any other python/bitbake hacker: maybe add sanity check if TMPDIR does not end on / (or strip it off)
May 26 06:29:22 <khem`> yeah I have a big fat warning in my local.conf
May 26 06:29:45 <khem`> eFfeM_work: we can add it to local.conf.sample
May 26 06:29:48 <eFfeM_work> khem` can you share that line ?
May 26 06:29:54 <eFfeM_work> khem` good plan
May 26 06:30:38 <eFfeM_work> ls
May 26 06:30:46 <khem`> #!!!!!!!!!!!!!!!!!! dont place a trailing slash on tmp dir !!!!!!!!!!
May 26 06:30:48 <khem`> # http://www.mail-archive.com/angstrom-distro-devel@linuxtogo.org/msg02922.html
May 26 06:31:14 <eFfeM_work> khem` ahh thought you had an actual test for it
May 26 06:32:11 <khem`> eFfeM_work: no test for it but wouldn't hurt to add to sanity class
May 26 06:32:52 <eFfeM_work> khem` yeah, but my python knowledge is mainly reading so don't really feel comfortable developing one
May 26 06:34:56 <khem`> ok
May 26 06:40:35 <mckoan> good morning
May 26 06:44:56 <khem`> eFfeM_work: Can you test this patch for me plz
May 26 06:44:58 <khem`> http://pastebin.com/Pu1rc1YQ
May 26 06:49:46 <eFfeM_work> khem` will do
May 26 06:49:52 <khem`> thx
May 26 06:52:37 <janp> khem`: I think that there is a closing '"' missing from your patch but otherwise it looks good.
May 26 06:55:30 <khem`> janp: right. thx
May 26 06:55:59 <eFfeM_work> khem` suggest to move the code to before the place where the test for TMPDIR changed location is
May 26 06:57:37 <eFfeM_work> patch looks good but for some reason I can't trigger the message, still trying
May 26 06:59:53 <khem`> eFfeM_work: try this patch instead 
May 26 06:59:55 <khem`> http://pastebin.com/2u8x71Sr
May 26 07:00:04 <khem`> I moved it to some other location
May 26 07:06:01 <ericben> hi khem
May 26 07:06:27 <ericben> I've put a native-sdk image on an arm926 using Angstrom distro and I don't have the shadow problem you meet
May 26 07:10:47 <khem`> eFfeM_work: http://pastebin.com/k6qtT7hf try that one it had a typo
May 26 07:10:55 <khem`> ericben: I have found the issue
May 26 07:11:07 <ericben> khem: what is it ?
May 26 07:11:28 <khem`> ericben: the problem is that on qemu serial console is ttyAMA0 and there is no entry for it in securetty
May 26 07:12:06 <khem`> ericben: once I add that and zap_root_password it seems to work well
May 26 07:12:45 <khem`> I will patch shadow for new ttps
May 26 07:12:47 <khem`> ttys
May 26 07:13:07 <ericben> khem: OK fine maybe we should find a way to create securetty from a variable in machine's conf file ?
May 26 07:13:31 <eFfeM_work> khem` that last one works for me, had indeed problems getting the message out and did not see the typo due to lack of python knowledge
May 26 07:13:38 <khem`> yeah we can create /etc/inittab 
May 26 07:13:48 <khem`> so whynot etc/securetty as well
May 26 07:14:13 <ericben> yes this way each machine will have it's own securetty and not a secruretty containing all ports of every machines
May 26 07:14:26 <khem`> yes
May 26 07:18:37 <eFfeM_work> khem` will you push the patch, feel free to add an Acked-By from me
May 26 07:23:25 <hrw> morning
May 26 07:23:31 <eFfeM_work> hi
May 26 07:24:05 <khem`> ericben: http://pastebin.com/WCFQrAhn
May 26 07:24:13 <khem`> something like this will work
May 26 07:24:16 <khem`> I am trying it now
May 26 07:24:34 <khem`> eFfeM_work: patches to classes need acks
May 26 07:24:42 <khem`> eFfeM_work: I will sent it to ml for review
May 26 07:24:46 <khem`> and you can ack it then
May 26 07:24:55 <eFfeM_work> khem` ok, will ack it as soon as i see it
May 26 07:24:59 <khem`> hrw: morning
May 26 07:27:14 <ericben> khem: yes and we may remove all serial console from files/securetty don't you think ?
May 26 07:27:57 <ericben> maybe this will break to many machines if SERIAL_CONSOLE is not set in their conf file
May 26 07:31:43 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rd3d5978587 10openembedded.git/recipes/gnome/ (gnome-dvb-daemon_0.1.17.bb gnome-dvb-daemon_0.1.18.bb): gnome-dvb-daemon: add 0.1.18, fix up 0.1.17
May 26 07:31:44 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r65253e1774 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev
May 26 07:31:45 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * re71818be2f 10openembedded.git/recipes/ti/ (gstreamer-ti/mpeg2-caps.patch gstreamer-ti_svn.bb): gstreamer-ti: add mpeg2 caps, patch from gst-ti svn
May 26 07:34:25 <CIA-1> 03Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r473f50a0a5 10openembedded.git/recipes/linux/ (linux-zigbee/imote2/defconfig linux-zigbee_git.bb): 
May 26 07:34:25 <CIA-1> linux-zigbee: Add recipe for the linux-zigbee tree
May 26 07:34:25 <CIA-1> Zigbee development tree which contains patches that have not yet hit mainline.
May 26 07:34:25 <CIA-1> Known working machine is imote2 at the moment.
May 26 07:34:35 <CIA-1> 03Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r754ea5aa93 10openembedded.git/conf/machine/imote2.conf: imote2.conf: Switch kernel to linux-zigbee
May 26 07:40:35 <khem`> ericben: I wouldnt go about removing entried from securetty 
May 26 07:40:48 <khem`> that will be living on edge
May 26 07:49:42 <khem`> ericben: this will also make shadow machine specific package 
May 26 07:50:26 <ericben> khem: maybe securetty should have its own package when SERIAL_CONSOLE is defined ?
May 26 07:50:46 <ericben> and stay generic if SERIAL_CONSOLE is not defined
May 26 08:40:53 <hrw> for Ubuntu I made a script which runs getty on serial console (if console= is present in kernel cmdline)
May 26 09:03:08 <khem`> hrw: http://pastebin.com/jm52Wm1G is what I am going to propose for OE :)
May 26 09:04:04 <JaMa|Wrk> 2.6.34-r1+gitr30 is lower version from opkg view than 2.6.34-oe2+gitr1? stupid /me :/
May 26 09:04:22 <hrw> looks ok
May 26 09:11:41 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r798066d5b2 10openembedded.git/recipes/nfs-utils/ (2 files in 2 dirs): 
May 26 09:11:41 <CIA-1> nfs-utils: add patch for missing include sys/stat.h
May 26 09:11:41 <CIA-1> * without, it fails with undefined reference to S_ISREG (the same for S_ISDIR)
May 26 09:11:41 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 26 09:11:41 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r8935ad53ba 10openembedded.git/recipes/e17/e-tasks_svn.bb: e-tasks: bump SRCREV for version compatible with latest EFL theme API change
May 26 09:11:46 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r3a92bc9fcf 10openembedded.git/recipes/linux/ (18 files in 3 dirs): 
May 26 09:11:46 <CIA-1> linux-openmoko: drop 2.6.31 and shr-drm-devel (2.6.29-rc3+drm patches) version
May 26 09:11:46 <CIA-1> * 2.6.32 version is superior in all aspects
May 26 09:11:46 <CIA-1> * this versions have WSOD issue on every resume (so not as usable as
May 26 09:11:47 <CIA-1> 2.6.32 where it's fixed)
May 26 09:11:47 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 26 09:11:48 <CIA-1> Acked-by: Khem Raj <raj.khem@gmail.com>
May 26 09:19:40 <JaMa|Wrk> khem`: FYI: after your udev commit, udev-utils for version 151 seems empty (and then image build fails because hald RDEPENDS on it)
May 26 09:20:24 <khem`> JaMa|Wrk: hmm
May 26 09:21:43 <hrw> udevadm got moved from udev-utils?
May 26 09:23:24 <JaMa|Wrk> hrw: yes, see http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=523f22b938703b56a823fa9e9c577869669ddb82
May 26 09:23:37 <hrw> JaMa|Wrk: that explain empty udev-utils
May 26 09:23:49 <hrw> or suggests it
May 26 09:25:53 <khem`> hrw: yeah I moved it into udev
May 26 09:26:10 <JaMa|Wrk> yes, there is no udevinfo,udevtest so it's empty, but not sure if it's proper fix to change hal to RSUGGEST it only
May 26 09:26:13 <khem`> but it seems that was the only package
May 26 09:26:19 <hrw> khem`: so you reverted my changes basically
May 26 09:26:29 <khem`> only file I meant in that package
May 26 09:26:31 <khem`> hmm
May 26 09:27:02 <hrw> systems without udev but with hald will now need udev to get hal working
May 26 09:27:14 <hrw> anyway hal is deprecated 
May 26 09:27:17 <khem`> hrw: yeah I see that
May 26 09:27:51 <khem`> are there OE disto's needing hald
May 26 09:27:51 <hrw> so mdev based systems will behave strange
May 26 09:28:03 <hrw> no idea
May 26 09:28:06 <hrw> hal should die
May 26 09:28:16 <khem`> anyway I think I should just ressurrect it
May 26 09:32:12 <JaMa|Wrk> hmm only xf86-input-tslib is pulling hal to my images
May 26 09:39:02 <CIA-1> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r6c5064f006 10openembedded.git/recipes/udev/ (udev.inc udev_151.bb): 
May 26 09:39:02 <CIA-1> udev: Move udevadm back from udev to udev-utils package.
May 26 09:39:02 <CIA-1> * hald needs udevadm but not all of udev. If this binary
May 26 09:39:02 <CIA-1> is moved into udev then it will have to pull in udev
May 26 09:39:02 <CIA-1> which is unwanted.
May 26 09:39:03 <CIA-1> Signed-off-by: Khem Raj <raj.khem@gmail.com>
May 26 09:48:25 <ant_work> while you guys are talking about udev, I was testing the koen's hack for devices running older kernels
May 26 09:48:28 <ant_work> http://lists.linuxtogo.org/pipermail/angstrom-distro-devel/2010-April/003908.html
May 26 09:49:10 <eFfeM_work> hm, trying to build with an external toolchain, but can't get oe to stp building gcc-cross-initial? any idea why? bitbake helloworld works, but bitbake busybox somehow creates a dependency towards gcc-cross-iniitial
May 26 09:50:43 <khem`> add gcc-cross-initial in the PROVIDE
May 26 09:50:44 <ant_work> khem: if you still have some pre 2.6.27 kernels please test it you too.
May 26 09:50:50 <khem`> list of external toolchain
May 26 09:51:02 <khem`> ant_work: which one
May 26 09:51:07 <ant_work> udev-static(_124) is required
May 26 09:51:18 <ant_work> the Angstrom one linked above
May 26 09:51:55 <eFfeM_work> khem I have ASSUME_PROVIDED += " gcc-cross-initial " in my local.conf (as well as virtual/gcc-cross-initial and virtual/${TARGET_PREFIX}gcc-cross-initial
May 26 09:54:02 <eFfeM_work> thought that would do the trick, but no
May 26 09:56:47 <eFfeM_work> :q
May 26 09:57:08 <eFfeM_work> oops, guess you all know what editor i use ;-)
May 26 09:58:08 <hrw> eFfeM_work: emacs in vi mode?
May 26 10:00:47 <ant_work> khem: once tested we could patch udev's init for other distro's too. Still deciding where to add dependency on udev-static. Perhaps even in the _151 recipe if kernel < .27?
May 26 10:03:10 <recalcati> hi all
May 26 10:03:25 <florian> hi recalcati 
May 26 10:03:42 <recalcati> we are going on developing with OE
May 26 10:04:33 <recalcati> I should clean and send back a modification for udev
May 26 10:05:18 <shazkhan> Hi everyone :)
May 26 10:05:39 <recalcati> And also I'm trying to use OE for creating a development environment. I mean compiling in a git tree not inside work dir.
May 26 10:06:12 <shazkhan> Any hints how to build for qemu-arm because its .conf is pretty empty? Will it work for SHR?
May 26 10:06:17 <khem`> recalcati: symlinking ?
May 26 10:06:44 <khem`> shazkhan: it should
May 26 10:06:50 <recalcati> symlinking .. or creating a devshell script that do a 'cd /home/myapps' 
May 26 10:07:05 <shazkhan> khem: what about x86
May 26 10:07:09 <khem`> just choose MACHINE=qemuarm DISTRO=<whatever>
May 26 10:07:14 <shazkhan> k
May 26 10:07:31 <khem`> shazkhan: same for x86
May 26 10:07:50 <khem`> MACHINE=qemux86
May 26 10:08:36 <khem`> hrw: /etc/shadow is not a packaged file I think its generated am I right ?
May 26 10:08:59 <hrw> khem`: never checked
May 26 10:12:37 <khem`> hrw: ok
May 26 10:24:52 <mckoan> recalcati: what would be the benefit of compiling in a git tree?
May 26 10:40:08 <recalcati> hi mckoan .. I was away
May 26 10:41:19 <recalcati> the steps are: 1. git clone from my server 2. compiling 3. installing 4. git committ 5. git push
May 26 10:42:22 <recalcati> the important thing is that the developing directory has to be a git tree, because a can easily manage differences with git diff, git status, ...
May 26 10:46:02 <khem`> zap_root_password  what does that supposed to do ?
May 26 10:46:30 <khem`> should it kill the root passwd and let root be passwordless or should it disable root user
May 26 10:46:43 <khem`> right now with shadow it seems to be doing the later
May 26 10:47:27 <hrw> it was for non-shadow systems
May 26 10:52:24 <khem`> hrw: so it should make root passwordless is that expected behaviour ?
May 26 10:52:39 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r809138a4a1 10openembedded.git/recipes/xorg-driver/xf86-input-tslib_0.0.6.bb: 
May 26 10:52:39 <CIA-1> xf86-input-tslib: lower hal dependency to RSUGGESTS as this is only recipe pulling hal/udev-utils to some images
May 26 10:52:39 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 26 11:06:40 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rbab8cda39a 10openembedded.git/ (12 files in 4 dirs): (log message trimmed)
May 26 11:06:40 <CIA-1> linux-openmoko: rename recipes to common PN_PV scheme, cleanup versioning
May 26 11:06:40 <CIA-1> * move DESCRIPTION to .inc
May 26 11:06:40 <CIA-1> * remove OEV, KERNEL_RELEASE and KERNEL_VERSION, keep KERNEL_* from
May 26 11:06:40 <CIA-1> kernel.bbclass
May 26 11:06:41 <CIA-1> * update distro/machine configs where needed
May 26 11:06:41 <CIA-1> Acked-by: Khem Raj <raj.khem@gmail.com>
May 26 11:06:51 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r351c813bae 10openembedded.git/recipes/linux/ (2 files in 2 dirs): 
May 26 11:06:51 <CIA-1> linux-openmoko: remove linux-openmoko-devel as it will be merged with linux-openmoko-shr-devel to linux-openmoko_2.6.29
May 26 11:06:51 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 26 11:06:51 <CIA-1> Acked-by: Khem Raj <raj.khem@gmail.com>
May 26 11:07:30 <dcordes> khem, as I said I only changed the following. what do I have to add/remove ?
May 26 11:07:37 <dcordes> -TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon ${ARM_FP_OPT}"
May 26 11:07:37 <dcordes> +TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 ${ARM_FP_OPT}"
May 26 11:08:11 <hrw> hi mickey|office 
May 26 11:08:24 <hrw> dcordes: targetting marvell cpus?
May 26 11:08:48 <dcordes> hrw, no it's for the htcleo machine with qsd8250 (snapdragon)
May 26 11:09:13 <mickey|office> morning
May 26 11:09:24 <hrw> snapdragon also lacks neon?
May 26 11:09:38 <dcordes> hrw, using the given cortex-a8 configuration in oe it will spit segfaults etc
May 26 11:10:12 <dcordes> hrw, it's supposed to have neon. and I ran some things successfully with neon optimization, e.g. mplayer
May 26 11:11:31 <dcordes> hrw, I think the stuff that fails (so far udevd, dropbear.. ) doesn't even have neon optimization
May 26 11:12:15 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rb671c1a87c 10openembedded.git/recipes/gnome/gnome-dvb-daemon_0.1.18.bb: gnome-dvb-daemon: depend on totem to build totem-plugin
May 26 11:12:26 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r0c34003764 10openembedded.git/ (recipes/tcltk/tcl_8.5.8.bb site/arm-linux): tcl: add 2 entries to arm-linux site file (possibly only glibc specific, need to check)
May 26 11:22:56 <GNUtoo> hi ericben 
May 26 12:32:40 <ericben> hi GNUtoo
May 26 12:34:43 <GNUtoo> ericben, hi
May 26 12:35:19 <GNUtoo> I saw your post on the alsa-devel mailing list, you also need to wire an imx to a tlv320aic codec
May 26 12:35:46 <ericben> yes, it was working using an old kernel, but I'm actually working at mainlining all my platforms
May 26 12:35:56 <GNUtoo> wow
May 26 12:36:40 <GNUtoo> I've a(two in fact) bug device( i.MX31) with a module containing a tlv320aic3x
May 26 12:36:57 <GNUtoo> the default driver was not writen using the alsa soc
May 26 12:37:02 <ericben> same here ;-)
May 26 12:37:04 <GNUtoo> it plays too fast 
May 26 12:37:18 <ericben> mine is a TLV320AIC23B
May 26 12:37:23 <GNUtoo> so I really want to have something usable
May 26 12:37:52 <ericben> I don't have i.MX31 here, I only have i.MX25/27/35/51 ;-)
May 26 12:38:08 <GNUtoo> ok
May 26 12:38:25 <ericben> but if the i.MX31 SSI port is the same as the 27 this should work
May 26 12:38:32 <GNUtoo> I'll look
May 26 12:38:43 <GNUtoo> I've used the driver of redhatter gentoo developer
May 26 12:38:49 <GNUtoo> which was posted in the mailing list
May 26 12:38:55 <GNUtoo> it didn't work
May 26 12:39:01 <GNUtoo> no sound card found
May 26 12:39:12 <GNUtoo> I'll look for ssi for imx31
May 26 12:39:21 <ericben> there is driver for your codec in soc/codecs : tlv320aic3x 
May 26 12:40:56 <GNUtoo> yes I know 
May 26 12:41:00 <GNUtoo> that's what I used
May 26 12:41:01 <ericben> I can send you my soc adaptation but it's very simple. The first thing to check is if the SSI of the 31 is the same of the 27
May 26 12:41:09 <GNUtoo> ok
May 26 12:41:15 <GNUtoo> maybe that's why I have an issue
May 26 12:41:23 <GNUtoo> in 2.6.27 I have:
May 26 12:41:25 <GNUtoo> built-in.o  Kconfig  Makefile  modules.order  registers.h  ssi.c  ssi.h  ssimod.o  ssi.o  ssi_types.h
May 26 12:41:42 <GNUtoo> in drivers/mxc/ssi
May 26 12:41:57 <GNUtoo> but someone did an initial 2.6.30 port
May 26 12:41:58 <ericben> GNUtoo: I'm using GIT so it's in drivers/soc/imx
May 26 12:42:12 <GNUtoo> in my 2.6.30 version it's here too
May 26 12:42:18 <GNUtoo> I imported it from 2.6.34
May 26 12:42:20 <ericben> I think you should switch to git as i.MX support is far better nos
May 26 12:42:21 <ericben> now
May 26 12:42:32 <GNUtoo> ah there is an imx git?
May 26 12:42:42 <GNUtoo> or do you mean linux-2.6 git
May 26 12:42:43 <GNUtoo> ?
May 26 12:43:47 <GNUtoo> ( git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git )
May 26 12:43:52 <ericben> yes in fact I'm using linux-2.6 git + mxc-master branch of : http://git.pengutronix.de/?p=imx/linux-2.6.git;a=summary
May 26 12:43:58 <GNUtoo> ahhh ok
May 26 12:44:00 <GNUtoo> thanks a lot!!!
May 26 12:44:26 <GNUtoo> which branch?
May 26 12:44:40 <eFfeM_work> khem: read your email, isn't is possible to extend the sed script in autotools.bbclass with something like s@//@/@g ?
May 26 12:45:00 <eFfeM_work> not really a wiz in that area (and no time to test right now)
May 26 12:46:25 <ericben> GNUtoo: mxc-master
May 26 12:46:31 <GNUtoo> ok thanks a lot
May 26 12:47:11 <ericben> GNUtoo: if the sound if too fast, maybee you need to look at the divisor in the codec as it is the master
May 26 12:47:24 <GNUtoo> ok
May 26 13:13:33 <ericben> GNUtoo: is your codec connected in I2S mode ?
May 26 13:14:23 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r7448905b37 10openembedded.git/conf/distro/shr.conf: 
May 26 13:14:23 <CIA-1> SHR: use eglibc-2.12 instead 2.11
May 26 13:14:23 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 26 13:14:25 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r8bb53d3f26 10openembedded.git/ (8 files in 2 dirs): 
May 26 13:14:25 <CIA-1> linux-openmoko: partial revert of rename to PN_PV sheme
May 26 13:14:25 <CIA-1> * details in http://thread.gmane.org/gmane.comp.handhelds.openembedded/32950
May 26 13:14:25 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 26 13:14:26 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rfa8b49b614 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev
May 26 13:19:05 <GNUtoo> ericben, it is
May 26 13:19:36 <ericben> GNUtoo: then, at line 101 of soc/imx/imx-ssi.c change to : scr |= SSI_SCR_NET | 0x40;
May 26 13:19:45 <ericben> if I remove this here, the sound goes far to fast
May 26 13:20:15 <ericben> as on my scope, the SSI signals are not in I2S mode using the default driver's configuration
May 26 13:20:46 <GNUtoo> ok thanks a lot!!!!
May 26 13:20:50 <ericben> if that also works for you, please answer to the thead on alsa-devel
May 26 13:20:58 <GNUtoo> ok
May 26 13:21:07 <GNUtoo> I'll try on 2.6.27 on the bad driver
May 26 13:21:19 <GNUtoo> because the new one doesn't work yet
May 26 13:21:58 <ericben> is the 2.6.27 the driver from the original FSL BSP ?
May 26 13:22:12 <GNUtoo> no
May 26 13:22:17 <GNUtoo> FSL?
May 26 13:22:34 <hrw> freescalelinux?
May 26 13:22:35 <GNUtoo> s/no/I don't know
May 26 13:22:39 <GNUtoo> ah I don't know
May 26 13:22:41 <GNUtoo> maybe
May 26 13:27:56 <GNUtoo> I think so
May 26 13:27:58 <GNUtoo>  * Copyright 2004-2006 Freescale Semiconductor, Inc. All Rights Reserved.
May 26 13:29:30 <ericben> GNUtoo: so check the where they set the SCR register of the SSI
May 26 13:29:48 <ericben> sorry FSL : Freescale ;-)
May 26 13:30:27 <ericben> that's the 3 letter name of their stock ;-)
May 26 13:30:46 <GNUtoo> ok
May 26 13:30:59 <GNUtoo> reg |= ((frame_rate_divider & AC97_FRAME_RATE_MASK) ?
May 26 13:32:14 <GNUtoo> http://pastebin.com/R3QQNtdR
May 26 13:32:40 <ericben> you are not is ac97 mode
May 26 13:33:10 <GNUtoo> ouch ok
May 26 13:34:13 <GNUtoo> maybe ssi_tx_frame_rate then
May 26 13:35:02 <ericben> no this is where they configure the SSI signal format, they will touch at SCR & STCR & SRCR
May 26 13:35:17 <GNUtoo> http://pastebin.com/6yrKXUKe
May 26 13:35:28 <GNUtoo> ok sorry I'll look
May 26 13:35:49 <ericben> GNUtoo: pastebin the whole file if you want
May 26 13:35:54 <GNUtoo> ok thanks
May 26 13:38:44 <GNUtoo> ssi.c : http://pastebin.com/Kmgs7XcD
May 26 13:39:31 <ericben> so check in your sound driver where is calls ssi_i2s_mode
May 26 13:39:34 <GNUtoo> the driver: http://pastebin.com/7JgGyMy9
May 26 13:39:36 <GNUtoo> ok
May 26 13:40:15 <GNUtoo> it does
May 26 13:40:16 <GNUtoo> 	ssi_i2s_mode (ssi, i2s_master);
May 26 13:40:44 <ericben> isn't your codec the master ?
May 26 13:41:29 <GNUtoo> I'll look
May 26 13:42:46 <GNUtoo> but where should I look?
May 26 13:42:57 <GNUtoo> I'm really sorry beeing such a noob on sound
May 26 13:43:08 <GNUtoo> specially on imx sound
May 26 13:43:15 <ericben> if the codec provides the clock and the frame it is master
May 26 13:43:33 <ericben> has your codec a crystal or an oscillator ?
May 26 13:45:29 <GNUtoo> I'll look here: http://bugcommunity.com/wiki/images/f/f5/B2_mod_audio_v1_1_2009_01_24.pdf
May 26 13:46:16 <ericben> yes it gets a 12MHZ clock
May 26 13:46:33 <GNUtoo> ok
May 26 13:47:00 <ericben> so you can configure it as master
May 26 13:47:40 <GNUtoo> ok
May 26 13:47:53 <GNUtoo> should I configure the codec as master?
May 26 13:47:57 <ericben> in that case it will provide the right clock & frame sync to the SSI
May 26 13:48:11 <ericben> TLV = master, SSI = slave
May 26 13:48:22 <GNUtoo> ok
May 26 13:48:25 <ericben> that's my configuration with the TLV320AIC23B and a  12MHz Xtal
May 26 13:48:30 <GNUtoo> ok
May 26 13:48:58 <GNUtoo> the tlv datasheet said ti could act as master if I remember well
May 26 13:50:21 <eFfeM_work> is makefile.am made from makefile.in or the other way around ?
May 26 13:51:16 <GNUtoo> eFfeM_work, maybe look in the Makefile.something maybe they tell that it's autogenerated and tell from where else consult the autotools pdf
May 26 13:51:26 <eFfeM_work> yeah googled inbetween
May 26 13:51:34 <GNUtoo> http://www.lrde.epita.fr/~adl/autotools.html
May 26 13:51:39 <eFfeM_work> automake processes Makefile.am to produce a  standards-compliant Makefile.i
May 26 13:51:47 <GNUtoo> ok
May 26 13:51:54 <eFfeM_work> thanks
May 26 13:51:57 <GNUtoo> np
May 26 13:53:18 <GNUtoo> ericben, is it hard to set TLV to master and SSI to slave?
May 26 13:55:31 <GNUtoo> (will I have to modify all the driver like nearly rewrite it or is it just a config)
May 26 13:59:01 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * ra0acdeec00 10openembedded.git/recipes/dri/ (7 files): 
May 26 13:59:01 <CIA-1> libdrm: add libdrm.inc, INC_PR and move to new staging
May 26 13:59:01 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 26 14:02:16 <ericben> GNUtoo: only one bit in the interface register to set I think
May 26 14:02:27 <GNUtoo> ah ok thanks a lot!!!
May 26 14:02:49 <ericben> gnutoo: I think it's name is something_MS or MS_something
May 26 14:03:56 <GNUtoo> ok I'll look
May 26 14:06:08 <GNUtoo> imx-ssi.h:#define SSI_SCR_I2S_MODE_MSTR	(1 << 5) ?
May 26 14:06:16 <GNUtoo> in penguintronix
May 26 14:06:28 <ericben> GNUtoo: that's for the SSI side which must be device
May 26 14:06:29 <GNUtoo> I'll look the equivalent in buglabs's driver
May 26 14:06:35 <GNUtoo> ok
May 26 14:09:19 <GNUtoo> ok in aic3x_set_dai_fmt there is master-slave thing in penguintronix I'll look in 2.6.27
May 26 14:10:53 <GNUtoo> I think I must go soon....sport...too bad
May 26 14:12:52 <CIA-1> 03Michael Lippautz <michael.lippautz@gmail.com> 07org.openembedded.dev * r6f56f5d29b 10openembedded.git/recipes/python/python-oauth_1.0.1.bb: 
May 26 14:12:52 <CIA-1> python-oauth: Add python library for OAuth
May 26 14:12:52 <CIA-1> Signed-off-by: Michael Lippautz <michael.lippautz@gmail.com>
May 26 14:20:19 <GNUtoo> and phone is still broken,shr apps which isn't mickeyl's task are broken on htcdream
May 26 14:20:31 <GNUtoo> s/shr apps/shr phone apps/
May 26 14:20:44 <GNUtoo> ooops wrong channel
May 26 14:21:28 <melchior__> hello, i'm using an embedded system wirth 64 MB of ram, but my linux detects 256 MB, how could i correct it ?
May 26 14:22:21 <ericben> melchios__: what kind of platform is it ?
May 26 14:24:52 <melchior__> arm
May 26 14:25:12 <marex> hi, guys, is it possible to still use Xserver-xfbdev on OE ?
May 26 14:25:14 <ericben> you need to configure your bootloader to pass the right setting to the kernel
May 26 14:25:26 <ericben> or add mem=64M to your kernel command line
May 26 14:26:25 <marex> melchior__, what ARM ?
May 26 14:26:30 <melchior__> ok, i'll try it
May 26 14:26:44 <melchior__> arm kirkwood from marvell
May 26 14:26:53 <marex> melchior__, you can also try mem=64M@address where address is the base address of memory block
May 26 14:27:15 <marex> ao2, hey bud
May 26 14:32:33 <animist> melchior__, memory configuration is done in bootloader, not Linux. So, you have to fix your bootloader
May 26 14:38:02 <marex> animist, not really, he can pass the "mem=" option as the worst possibility
May 26 14:38:08 <melchior__> i've been looking for CFG_DRAM_CHIP_SIZE in the sources but can't find it, isn't it the variable i need to set ?
May 26 14:38:18 <marex> melchior__, u-boot ?
May 26 14:38:22 <melchior__> yes
May 26 14:38:30 <marex> include/configs/your_plat
May 26 14:38:54 <melchior__> i've done rgrep and got no results
May 26 14:39:05 <marex> CONFIG_SYS_DRAM_SIZE ?
May 26 14:39:21 <ericben> melchior: but you must also configure the RAM initialization as if you don't have the same chip geometry as it's configured, this won't work 
May 26 14:39:46 <marex> try also board/yourplat/yourplat.c dram_init()
May 26 14:39:54 <marex> gd->bd->bi_dram[0].start look for something like this
May 26 14:40:15 <animist> marex, "mem=" option can save sometimes in simple situations, but it won't help if RAM chips are configured incorrectly in a bootloader
May 26 14:40:59 <marex> animist, the bootloader won't even start if it copied itself into ram buggered in such a way (And that's the most common case)
May 26 14:41:41 <animist> different RAM quantity means different chips even on a similar platform
May 26 14:44:47 <animist> marex, yep, it won't start in the worst case.
May 26 14:44:51 <marex> animist, don't worry, I maintain u-boot-pxa :-)
May 26 14:45:13 <marex> animist, that's very likely it won't start ... but it runs for him
May 26 14:45:23 <marex> animist, so he very likely has only wrong ATAGS
May 26 14:45:24 <animist> ah, ok. I send you a "hello" word from Kschevetsky ;)
May 26 14:45:37 <animist> and from sergey Lapin
May 26 14:45:38 <marex> animist, ah ... you know him? say hello to him as well :)
May 26 14:45:40 <marex> oh :/
May 26 14:45:46 <animist> :p
May 26 14:45:50 <marex> animist, I'll have a drink for him
May 26 14:46:00 <marex> that'd make him happy ... or did he stopped drinking ?
May 26 14:46:36 <animist> not yet, today I'll meet him in a pub a bit later :)
May 26 14:46:48 <marex> animist, still in SP ?
May 26 14:46:55 <marex> say hi to him from me :)
May 26 14:57:36 <animist> marex, yes, still in SP
May 26 14:58:30 <marex> animist, and still fscking with sluts ... just like I knew him :-)
May 26 15:07:42 <kergoth>  damn, what am i missing here..
May 26 15:07:43 <kergoth> hmm
May 26 15:09:19 <kergoth> trying to kill the OVERRIDES manipulations where we don't absolutely have to use them
May 26 15:09:42 <RP> morning all
May 26 15:10:02 <kergoth> ah, i think i see..
May 26 15:10:05 <kergoth> hey RP
May 26 15:10:28 <kergoth> RP: realized tasks manipulating overrides put a serious kink in tracking variable references :|
May 26 15:13:27 <RP> kergoth: hmm, I can imagine that. Was this do_package per chance?
May 26 15:13:39 <kergoth> a number of the packaging classes, yeah
May 26 15:13:52 <kergoth> i was thinking about a wrapper script that just checks FOO_<override> and falls back to FOO
May 26 15:13:57 <kergoth> s/script/python function/
May 26 15:13:59 <kergoth> heh
May 26 15:14:10 <RP> kergoth: Can we manually inject those dependencies?
May 26 15:14:15 <kergoth> either that or use the ast to try to track the override modification, but tahts difficult because its not a literal string
May 26 15:14:24 <RP> kergoth: That function will still cause problems since you won't know FOO ?
May 26 15:14:41 <kergoth> would have to tell the tracking code to treat that function like getVar
May 26 15:14:54 <kergoth> already added teh ability to specify explicit var refs in a flag, so thats an option
May 26 15:15:00 <RP> a special getVar :/
May 26 15:15:02 <kergoth> but dangerous, still
May 26 15:15:14 <RP> right, you'd probably need wildcards
May 26 15:15:35 <kergoth> guess we can add every var that comes out of a getVar() against the new localdata to the varrefs flag, and hope that covers it
May 26 15:16:15 <RP> It was never going to be a simple problem :/
May 26 15:16:17 * kergoth is, however, wondering about the wisdom of using overrides for those pkg specific things anyway.. it seems awfully implicit
May 26 15:16:25 <kergoth> yeah
May 26 15:16:29 <kergoth> another issue is side effects.
May 26 15:16:51 <kergoth> os.uname() pulls os specific information, yet i'm storing the components of the python snippet itself in the signature, not the *output* of the snippet
May 26 15:16:56 <kergoth> bb.which() is a problem too
May 26 15:17:05 <kergoth> capturing machine specific file:// usage..
May 26 15:17:09 <kergoth> it's definitely challenging :)
May 26 15:17:18 <RP> a variable that didn't exist bcoming set can massively influence that code. Do you track that?
May 26 15:19:05 <RP> For packaging, something that says it depends on the contents of "RDEPENDS* RRECOMMENDS* DESCRIPTION*" and so on might actually work quite well
May 26 15:19:12 <kergoth> currently, the tree holds the reference to it, it only becomes a ${FOO} string if FOO isn't set at resolve-time.  the signature will change when the referenced var shows up.  i'll have to double check that varrefs flag items are handled the same way
May 26 15:19:33 <kergoth> that could do.  otherwise, can do a ${@} iterating over PACKAGES
May 26 15:19:47 <kergoth> made sure it expands the flag :)
May 26 15:19:52 <RP> kergoth: remember that PACKAGES gets expanded at runtime though
May 26 15:20:08 <kergoth> hmm, true
May 26 15:20:14 <RP> kergoth: locale generation for example
May 26 15:20:48 <kergoth> alternatively, we could go based on PACKAGES+PACKAGES_DYNAMIC directly.. wildcards would work too of course, just seems silly to possibly pull in things it isn't really going to use
May 26 15:21:08 <kergoth> course, once this is integrated into bitbake as a stamps replacement, going based on PACKAGES might be fine, if it uses the value as of do_package execution time
May 26 15:21:27 <kergoth> this stuff gives me a headache :)
May 26 15:21:50 <RP> kergoth: We need to be able to calculate something for comparision without running anything though
May 26 15:21:57 <RP> kergoth: I'm pleased its not just me
May 26 15:22:16 <kergoth> this does function, finally, and is unit tested, but there are lots of little pieces that need to be worked out
May 26 15:22:20 <RP> PACKAGES+PACKAGES_DYANMIC should work
May 26 15:22:22 <kergoth> the 80% is there, that last 20 is going to suck :)
May 26 15:22:34 <RP> yes, that is going to make/break it :)
May 26 15:22:43 <RP> but its a massive improvement on where it was
May 26 15:23:22 <kergoth> http://github.com/kergoth/OE-Signatures/blob/3589fc6ea491879b0ab4480db97c637d5b2e2bbe/lib/test_kergoth.py
May 26 15:24:32 <RP> kergoth: neat. We should start getting into the habit of proper unit tests in the main repo that are easily runnable 
May 26 15:24:41 <kergoth> definitely
May 26 15:24:42 <RP> If we had that I'd add them to our autobuilder
May 26 15:25:29 <kergoth> another issue i've run into is the methodpool.  once a funciton goes into it, we never keep the string incarnation around, so can't analyze them without disassembling the python code object, which would be brittle.
May 26 15:25:39 <kergoth> i do track calls to methodpool functions, though
May 26 15:26:12 <RP> saving the string incarnation shouldn't be too hard?
May 26 15:27:02 <kergoth> god help us if we have a variable in the metadata with the same name as am ethodpool function, but no, it should be easy enough once i start looking at bitbake integration further
May 26 15:27:22 * kergoth goes to grab food & caffeine
May 26 15:27:31 <RP> kergoth: I think I made the names insane enough that shouldn't happen ;-)
May 26 15:27:51 <RP> kergoth: I've been promised some dedicated time to look at all this stuff soon btw. 
May 26 15:28:22 <kergoth> and of course, the bits i moved into the oe python package are an issue, *but*, i can always reparse those to obtain an ast to manipulate for those
May 26 15:29:29 <RP> kergoth: That is an unfortunate side effect although I guess it holds for lib/bb too
May 26 15:30:20 <marex> guys, is it possible to use xorg-xfbdev ?
May 26 15:34:47 <kergoth> wow.  hah.  insane.bbclass manipulates overrides, sets ROOT, sets ROOT_pkg, sets PKG, runs update_data, all to get at the pkg specific RDEPENDS
May 26 15:35:00 <kergoth> that's a tad .. excessive
May 26 15:57:09 <khem> kergoth: I am seeing problem when apply=yes is used 
May 26 15:57:31 <khem> kergoth: the patches gets copied to WORKDIR
May 26 15:58:02 <khem> and not into patches/ subdir inside $WORKDIR/<sources>
May 26 15:58:15 <khem> and also the series file dont list these patches anymore
May 26 15:58:20 <khem> so they dont get applied
May 26 16:00:20 <hrw> bye all
May 26 16:35:58 <khem> kergoth: btw. I think if one uses a patch file which does not end with .patch or .diff and then says file://my_weird_patch;apply=yes it thinks it as a file. I think apply keyword in params should have meant that its a patch irrespective of extention
May 26 16:36:12 <nik0n> hi. is there any reason why samba package is only at version 3.3? today i added a recipe for version 3.4/3.5 but running this on current dev branch with minimal distro will cause samba to coredump. using the 3.3 recipe that is provided will deny ´samba to transfer files. it always complains about "to less ram on client machine"
May 26 16:36:26 <khem> kergoth: but it seems it treats them as normal files
May 26 16:36:27 <nik0n> i know this isnt a samba support # but maybe someone had similar problems
May 26 16:37:17 <khem> kergoth: is there a param like type=<patch|normal file|archive> etc.
May 26 16:40:29 <khem> kergoth: something like http://pastey.net/136949 would work I guess
May 26 16:40:55 <khem> kergoth: but it would mean that apply is only applicable for patch files which is ok I guess
May 26 16:57:17 <CIA-1> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r5a12f03c68 10openembedded.git/recipes/tcp-wrappers/ (21 files in 2 dirs): 
May 26 16:57:17 <CIA-1> tcp-wrappers: Add .patch extention to patch files.
May 26 16:57:17 <CIA-1> Signed-off-by: Khem Raj <raj.khem@gmail.com>
May 26 16:57:27 <CIA-1> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * rfea59d5413 10openembedded.git/classes/image.bbclass: (log message trimmed)
May 26 16:57:27 <CIA-1> image.bbclass: Make zap_root_password to disable root's password not the user root itself.
May 26 16:57:27 <CIA-1> * With shadow now running pwconv after commit 7c5f81b2139e55622ca2f23ff6b63438d4825d87
May 26 16:57:27 <CIA-1> It converts :*: passwd entry into equivalent /etc/shadow entry :*:
May 26 16:57:28 <CIA-1> which in shadow means disable the account as per
May 26 16:57:28 <CIA-1> http://tldp.org/LDP/lame/LAME/linux-admin-made-easy/shadow-file-formats.html
May 26 16:57:29 <CIA-1> As a result root can not login unless one boots into shell and then
May 26 16:57:30 <CIA-1> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * ra60230a927 10openembedded.git/recipes/shadow/shadow.inc: (log message trimmed)
May 26 16:57:30 <CIA-1> shadow.inc: Append serial devices mentioned in SERIAL_CONSOLE into /etc/securetty
May 26 16:57:31 <CIA-1> * Some serial dev nodes are not part of /etc/securetty. So either
May 26 16:57:31 <CIA-1> we can add them manually or deduce from SERIAL_CONSOLE. this does
May 26 16:57:32 <CIA-1> the later. Tested on qemuarm which used ttyAMA0 for console and it
May 26 16:57:32 <CIA-1> not listed in the securetty list. This authorizes root login on
May 26 16:57:33 <CIA-1> the give named console.
May 26 17:06:12 <wroberts1> i got this error in qte-mt_2.3.10.bb
May 26 17:07:17 <wroberts1> something about bidimetrics.patch
May 26 17:08:01 <GNUtoo|oeee> wroberts1, the patch doesn't apply?
May 26 17:08:07 <GNUtoo|oeee> rebase it then
May 26 17:14:12 <khem> wroberts1: try this http://pastebin.com/zYQf6gCx
May 26 17:14:34 <khem> wroberts1: then clean and repatch the recipe
May 26 17:24:55 <JaMa|Wrk> khem: building all locales in eglibc_2.12 failed for es_CR.ISO-8859-1, but this one is not one of new (kok_IN, sq_MK, cv_RU), rechecking now
May 26 17:26:46 <JaMa> khem: probably related to this message NOTE: generating locale si_LK (U/usr/share/i18n/locales/es_CR:56: LC_MONETARY: unknown character in field `currency_symbol'
May 26 17:28:04 <JaMa> khem: currency_symbol      "<U20A1>"
May 26 17:28:09 <JaMa> any hint?
May 26 17:29:26 <JaMa> changed in http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/libc/localedata/locales/es_CR?rev=10196&r1=7311&r2=10196
May 26 17:31:04 <khem> yeah thats a bug fix btw 
May 26 17:32:30 <Crofton|work> q
May 26 17:34:10 <JaMa> khem: found it in http://www.mail-archive.com/debian-glibc@lists.debian.org/msg42902.html but it doesn't explain why building this locale fails :/
May 26 17:35:36 <JaMa> strange I reverted currency_symbol change (just for test) and it says same warning :/
May 26 17:38:02 <khem> JaMa: look into si_LK
May 26 17:39:23 <wroberts1> somehow when i run bitbake -b qte-mt_2.3.10, i dont have the right environment, so i just try bitbake opie-image
May 26 17:39:57 <wroberts1> but i did do first: bitbake -b qte-mt_2.3.10 -c clean
May 26 17:40:01 <JaMa> NOTE: generating locale si_LK (U/usr/share/i18n/locales/es_CR:56: LC_MONETARY: unknown character in field `currency_symbol'
May 26 17:40:04 <JaMa> TF-8)
May 26 17:40:56 <khem> wroberts1: do bitbake -c clean qte-mt
May 26 17:41:18 <khem> JaMa: ok so the error is in es_CR
May 26 17:41:33 <JaMa> khem: but si_LK has in header "% Charset: UTF-8" or is it only comment?
May 26 17:43:04 <JaMa> and si_LK is not built with ISO-8859-1 only with UTF-8
May 26 17:43:38 <khem> JaMa: now I am confused which one is failing
May 26 17:43:49 <khem> es_CR right
May 26 17:45:41 <JaMa> es_CR.ISO-8859-1 is failing
May 26 17:46:43 <JaMa> and calling "localedef... --inputfile=/usr/share/i18n/locales/es_CR --charmap=UTF-8 es_CR.UTF-8" doesn't complain about currency_symbol
May 26 17:47:34 <JaMa> have to go.. bbl
May 26 17:48:52 <khem> JaMa: pl
May 26 17:48:54 <khem> ok
May 26 17:48:59 <khem> me too
May 26 17:55:39 <khem> wroberts1: did it help ?
May 26 18:13:57 <wroberts1> i think so. its building opie-image, and im at task 2309 of 4234
May 26 18:40:01 <khem> wroberts1: ok cool thx
May 26 18:54:27 <CIA-1> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r40dc6c1497 10openembedded.git/recipes/qte/qte-common_2.3.10.inc: 
May 26 18:54:27 <CIA-1> qte-common_2.3.10.inc: remove striplevel=5
May 26 18:54:27 <CIA-1> Signed-off-by: Khem Raj <raj.khem@gmail.com>
May 26 18:54:38 <CIA-1> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r5439bfeae5 10openembedded.git/recipes/vim/vim_7.2.bb: 
May 26 18:54:38 <CIA-1> vim_7.2.bb: Add apply=no to 001-411.diff
May 26 18:54:38 <CIA-1> * This patch is applied manually in the recipe.
May 26 18:54:38 <CIA-1> Signed-off-by: Khem Raj <raj.khem@gmail.com>
May 26 18:54:56 <kergoth_> hmm, did my scripts screw those up?
May 26 18:55:31 <shazkhan> If a package does not depend on autotools and just make and pythin scripts then how should the recipe be handled? Are there any examples in current recipes that I should follow for a start? Please name a few.
May 26 18:55:51 <shazkhan> by make I mean Makefiles
May 26 18:56:02 <kergoth_> uh, look for recipes that don't inherit autotools?
May 26 18:56:30 <CIA-1> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r4a72268c21 10openembedded.git/contrib/qemu/run-qemu.sh: 
May 26 18:56:30 <CIA-1> run-qemu.sh: Pass libc as a parameter instead of modifying script
May 26 18:56:30 <CIA-1> Signed-off-by: Khem Raj <raj.khem@gmail.com>
May 26 19:04:41 <kergoth_> khem: did i break vim and qte-common with my sed's for the patch changes?
May 26 19:04:54 <khem> seems so
May 26 19:05:10 <kergoth_> weird.  those changes were really straightforward
May 26 19:05:13 <kergoth_> thanks for fixing em
May 26 19:05:18 <khem> kergoth_: I nuked my tmp and did a build of native sdk from scratch
May 26 19:05:22 <kergoth_> ah
May 26 19:05:36 <kergoth_> i did a -c patch -k world years ago, i didn't dare this time
May 26 19:05:38 <khem> kergoth_: btw. one nit I observed
May 26 19:05:38 <kergoth_> heh
May 26 19:06:33 <khem> if patch name is not ending with .patch or .diff and apply=no|yes is not used 
May 26 19:06:39 <khem> and it still is a patch file
May 26 19:06:43 <khem> then it breaks now
May 26 19:06:50 <kergoth_> not sure what you mean
May 26 19:06:57 <kergoth_> it just doesn't apply them in that case, no?
May 26 19:06:58 <khem> because it thinks it to be a normal file instead of a patch file
May 26 19:07:04 <khem> yeah
May 26 19:07:06 <kergoth_> that's no different than it was before
May 26 19:07:14 <kergoth_> if you didn't set patch=1, it didn't know it was a patch
May 26 19:07:26 <kergoth_> it only automatically does it based on extension, not file magic
May 26 19:07:36 <khem> patch=1 is set
May 26 19:07:40 <kergoth_> all the cases i found like that already have apply=yes specifically
May 26 19:07:41 <khem> or was set
May 26 19:07:47 <kergoth_> oh, the compatbility bits aren't behaving?
May 26 19:07:52 <kergoth_> okay, i'll look into it
May 26 19:08:02 <khem> tcp-wrappers
May 26 19:08:09 <kergoth_> thanks :)
May 26 19:08:46 <kergoth_> i thought i had that logic right, but it gets a little twisty
May 26 19:08:50 <kergoth_> heh
May 26 19:09:00 <khem> git show bf7d0467a0788a7fcc1c96e0dc35a25ae09278a0 recipes/tcp-wrappers/tcp-wrappers_7.6.bb
May 26 19:09:23 <khem> that was original change you did in your first commit
May 26 19:09:53 <kergoth_> ugh
May 26 19:09:54 <kergoth_> damnit
May 26 19:10:00 <khem> but then second commit screwed it
May 26 19:10:25 <kergoth_> hmm
May 26 19:10:30 <khem> sorry no
May 26 19:10:36 <khem> not the second one
May 26 19:10:38 <kergoth_> a show of 6fe7cef27069415f2eba36bc640cf59013d4979b doesn't see that
May 26 19:10:50 <khem> file://01_man_portability;apply=yes 
May 26 19:10:57 <khem> is not taken in as a patch 
May 26 19:10:59 <kergoth_> which is correct
May 26 19:11:01 <kergoth_> oh
May 26 19:11:12 <khem> thats the problem
May 26 19:11:16 <kergoth_> okay, i'm on it
May 26 19:11:26 <khem> to circumvent it I renamed the patches for this one recipe
May 26 19:11:36 <kergoth_> couldve sworn i tested that.  i picked a bunch of recipes with specific cases to try to unit test it :)
May 26 19:11:45 <khem> heh
May 26 19:11:54 <kergoth_> speaking of which, we need to gather those somewhere
May 26 19:12:01 <kergoth_> i have a set of them to test do_unpack
May 26 19:12:06 <kergoth_> somewhere
May 26 19:12:07 <khem> apply=yes|no should still convery patch=1 behaviour IMP
May 26 19:12:09 <khem> IMO
May 26 19:12:13 <kergoth_> yeah, it should
May 26 19:12:19 <kergoth_> patch=1 -> apply=yes, directly
May 26 19:13:21 <shazkhan> kergoth_ and khemIf a package does not depend on autotools and just make and Makefile and some python scripts then how should the recipe be handled? Are there any examples in current recipes that I should follow for a start? Please name a few ...
May 26 19:13:25 <khem> or if there is another attribute like type then that could be used too
May 26 19:13:47 <kergoth_> shazkhan: you should try actually reading teh responses to your questions
May 26 19:14:02 <khem> shazkhan: recipes/helloworld
May 26 19:14:29 * khem chuckles
May 26 19:14:44 <shazkhan> k ...
May 26 19:15:23 <shazkhan> is hello world that sophisticated?
May 26 19:15:36 <kergoth_> you didn't ask for a sophisticated example, did you?
May 26 19:15:55 <kergoth_> if you're too lazy to actually grep through the recipes, you can't be expecting too much
May 26 19:16:55 <shazkhan> hmmm
May 26 19:16:58 <khem> kergoth_: btw. native-sdk-image generated successfully (3900 tasks) so your scripts werent too bad
May 26 19:17:54 <kergoth_> thankfully most patches end in patch/diff, clearly :)
May 26 19:17:57 <khem> hmm if I grep for do_stage there are 1376 instances still 
May 26 19:18:04 <kergoth_> ouch
May 26 19:18:08 <shazkhan> the hello world does not use Makefile and it does not use any py scripts! But I will do the greps before asking more
May 26 19:18:24 <shazkhan> :(
May 26 19:18:41 <kergoth_> as i said liek 10 minutes ago and you conveniently ignored, look for recipes taht don't inherit autotools or qmake or whatever
May 26 19:18:47 <kergoth_> there are hundreds, if not more
May 26 19:19:04 <khem> kergoth_: IMO patches should be named .diff and .patch anyway 
May 26 19:19:20 <khem> ah it boots too gr8
May 26 19:19:33 <kergoth_> agreed
May 26 19:19:51 <khem> but we should have a way out for creeps :)
May 26 19:20:33 <khem> kergoth_: did patch > 1 conveyed anything more than patch=1
May 26 19:20:34 <likewise> khem: I rather would have it fail horribly so that it gets renamed
May 26 19:20:49 <kergoth_> khem: nope, the value was ignored, it used to just go by 'patch' bein in the parms at all
May 26 19:20:50 <khem> likewise: good idea though
May 26 19:21:53 <likewise> similar with 'multiple providers, set preferred_provider' , I would still like to see it fail. It bites many people and is non-deterministic
May 26 19:21:57 * khem can fix binutils do_stage
May 26 19:22:17 <khem> likewise: yes I do agree 
May 26 19:23:35 <khem> hmmm kergoth_ does empty do_stage make sense anymore
May 26 19:24:07 <kergoth_> hmm, not sure, would have to double check the legacy staging logic
May 26 19:29:01 <CIA-1> 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * r8cffbaec07 10openembedded.git/classes/base.bbclass: 
May 26 19:29:01 <CIA-1> base.bbclass: make do_unpack also not unpack when 'apply' url parameter is set
May 26 19:29:01 <CIA-1> Signed-off-by: Chris Larson <chris_larson@mentor.com>
May 26 19:29:02 <CIA-1> 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * ra56048dedf 10openembedded.git/classes/patch.bbclass: 
May 26 19:29:02 <CIA-1> patch.bbclass: fix the logic error that resulted in tcp-wrappers patch application failures
May 26 19:29:02 <CIA-1> Signed-off-by: Chris Larson <chris_larson@mentor.com>
May 26 19:29:10 <kergoth_> think that should do it
May 26 19:32:16 <khem> kergoth_: I hope file://my_patch.patch.bz2 will still work
May 26 19:32:39 <kergoth_> i verified that a patch.gz works, it was one of the recipes i tested
May 26 19:32:42 <kergoth_> so bz2 should as well
May 26 19:32:58 <kergoth_> erm.. damnit, you're right, i'd better double check
May 26 19:33:01 * kergoth_ mutters
May 26 19:33:24 * kergoth_ needs a vacation
May 26 19:34:35 <khem> kergoth_: actually I am ok with current syntax too where we ask for .patch and .diff extentions 
May 26 19:34:52 <kergoth_> right, yeah, the base unpack logic only happens for stuff that doesn't need to be unpacked
May 26 19:35:02 <kergoth_> it checks to see if its a patch to see if it can avoid "unpacking" it
May 26 19:35:02 <nik0n> i experienced a problem with expat 2.0.1 on different machines
May 26 19:35:03 <nik0n> NOTE: Unpacking ../sources/expat-2.0.1.tar.gz to tmp/work/avr32-oe-linux-uclibc/expat-2.0.1-r3/
May 26 19:35:06 <nik0n> gzip: stdin: invalid compressed data--crc error
May 26 19:35:15 <kergoth_> so we should be okay
May 26 19:35:18 <nik0n> anyone got a working version of expat?
May 26 19:35:45 <kergoth_> hmm
May 26 19:35:48 <khem> nik0n: what distro are you using
May 26 19:35:56 <nik0n> khem: minimal
May 26 19:35:57 <kergoth_> oh, right, it still unpacks patches that are assumed patches by extension.. fuck it
May 26 19:36:11 <kergoth_> doesn't actually harm anything, just copies the patches into workdir :)
May 26 19:36:25 <kergoth_> should move that logic into a function that both patch and unpack use to see if a given file is a patch
May 26 19:37:13 <khem> right
May 26 19:51:06 <kergoth_> why the hell is NoProvider an unknown event?
May 26 19:51:13 <kergoth_> it worries me that bitbake doesn't know one of its own events
May 26 19:51:27 <kergoth_> well, exception, but still
May 26 19:52:26 <khem> Providers.NoProvider
May 26 19:52:45 <kergoth_> yeah.. i don't need to see a traceback on that :)
May 26 19:52:49 <kergoth_> just tell me we don't have the damn thing
May 26 19:53:22 <khem> lib/bb/event.py says its event and lib/bb/providers.py seems to have exception
May 26 19:53:26 <khem> with same name
May 26 19:53:31 <kergoth_> aha
May 26 19:53:38 <kergoth_> we really need to audit our exception handling, across teh board
May 26 19:54:09 <khem> class NoProvider(Exception): """Exception raised when no provider of a build dependency can be found"""
May 26 20:27:17 <CIA-1> 03Antonio Ospite <ospite@studenti.unina.it> 07org.openembedded.dev * r583d8ac5f4 10openembedded.git/recipes/openmoko-projects/paroli_git.bb: 
May 26 20:27:17 <CIA-1> paroli: depend just on edbus, not on edbus-ehal
May 26 20:27:17 <CIA-1> edbus-ehal is not available anywhere in current metadata, just depend on
May 26 20:27:17 <CIA-1> edbus to make images which include paroli build.
May 26 20:27:17 <CIA-1> See also http://tinderbox.openembedded.org/packages/544404/
May 26 20:27:18 <CIA-1> Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
May 26 20:27:18 <CIA-1> Signed-off-by: Khem Raj <raj.khem@gmail.com>
May 26 20:43:54 <wroberts1> some problem with qte/qpe http://pastebin.com/NwbRXbZD
May 26 20:44:58 <IgorK> good day
May 26 21:06:54 <wroberts1> ERROR: libdrm-2.4.18: http://dri.freedesktop.org/libdrm/libdrm-2.4.18.tar.bz2 cannot check archive integrity
May 26 21:35:02 <khem> hmm may be we should rename org.openembedded.org to master
May 26 21:36:35 <ao2> Full ACK :)
May 26 21:40:00 <kergoth> khem: yes, yes, yes
May 26 21:40:05 <kergoth> i really, really hate our branch naming
May 26 21:40:12 <kergoth> something for the next TSC, perhaps
May 26 21:41:17 <khem> kergoth: yes thats a good topic
May 26 21:41:54 <khem> kergoth: I dont know how easy/difficult it would be
May 26 21:42:19 <kergoth> renaming them is easy, but everyone with a clone wouldn't be able to just 'pull' anymore
May 26 21:42:26 <kergoth> would have to change their local branch config
May 26 21:43:00 <khem> kergoth: hmm cant we change it with --track
May 26 21:43:16 <kergoth> not sure what you mean
May 26 21:43:33 <CIA-1> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r40d95cb213 10openembedded.git/recipes/dri/libdrm_2.4.18.bb: 
May 26 21:43:33 <CIA-1> libdrm_2.4.18.bb: Fix SRC_URI name in checksums.
May 26 21:43:33 <CIA-1> Signed-off-by: Khem Raj <raj.khem@gmail.com>
May 26 21:43:38 <kergoth> everyone with a clone has to either recreate their local branch(es) or alter the git-config vars
May 26 21:44:11 <khem> ah yes existing branches
May 26 21:44:26 <khem> git branch --track could be used
May 26 21:44:53 <kergoth> yeah
May 26 21:45:06 <khem> for new branches git checkout --track
May 26 21:45:07 <kergoth> sadly we can't do it all on the remote end, which is why its probably been put off for this long
May 26 21:45:15 <kergoth> pretty sure track is default nowadays
May 26 21:45:22 <kergoth> git checkout -b master origin/master or so
May 26 21:45:35 <khem> yeah thats default
May 26 23:19:23 <IgorK> Why there is no glib-dbg package in OE?
May 26 23:19:41 <kergoth_> what do you mean?
May 26 23:25:31 <kergoth_> damn, that didn't take long
May 26 23:25:44 * kergoth_ just added a patch to an src_uri in an external overlay without ;patch=1.. oops
May 27 00:22:37 <kergoth_> Tartarus: ping
May 27 00:24:47 <IgorK> kergoth_: I am looking for a way to put a debug symbols for a glib library
May 27 00:54:36 <IgorK> any idea what
May 27 00:54:46 <IgorK> this package called?
May 27 00:55:03 <IgorK> I mean glib-dbg
May 27 02:51:28 <khem> IgorK: its libglib-2.0-dbg
**** ENDING LOGGING AT Thu May 27 02:59:57 2010