**** BEGIN LOGGING AT Thu May 27 02:59:57 2010
May 27 04:16:48 * kergoth_ thinks about revamping the variable reference tracking code to use dumb nodes in an AST rather than objects that do their own traversing
May 27 04:32:20 <kergoth_> hmmmm
May 27 04:48:01 <IgorK> WHat is the difference between x11-gpe-image and gpe-image? is the first one - x11 and second GPE with X?
May 27 04:48:23 <IgorK> thanx khem
May 27 04:49:05 <IgorK> I updated the bug about binutils/nm. Thanx 4 looking into it.
May 27 05:03:40 <khem> IgorK: ok
May 27 05:03:46 <khem> I will fix it soon
May 27 05:09:46 <khem> IgorK: so this happens with cross binutils or target binutils
May 27 05:10:28 <IgorK> target binutils
May 27 05:11:37 <khem> IgorK: do you see it when you boot the root file system
May 27 05:12:01 <khem> I mean when you boot you dont have /usr/bin/nm ?
May 27 05:13:49 <IgorK> no, I didn't
May 27 05:14:43 <IgorK> unfortunately I removed it from the image, but it installed itself in osme funny path
May 27 05:15:21 <khem> well the real binary should be something like arm-angstrom-linux-gnueabi-nm
May 27 05:15:23 <IgorK> do you know the difference between x11-gpe and gpe?
May 27 05:15:24 <khem> in /usr/bin
May 27 05:15:30 <khem> and nm should be a symlink to it
May 27 05:15:42 <khem> as the name says
May 27 05:15:50 <khem> its GPE with X server
May 27 05:16:17 <IgorK> Understood, but just typing "nm" on my device gives "Unrecognized command"
May 27 05:16:40 <khem> ah and you have binutils installed on device right ?
May 27 05:17:07 <IgorK> I had, but it is removed now
May 27 05:17:53 <IgorK> I am building gpe-image. want to give it a try instead of x11-gpe
May 27 05:18:01 <IgorK> hence the question of difference
May 27 05:19:16 <IgorK> I can quickly rebuild x11-gpe-iimage with binutils just to test if u want to
May 27 05:28:14 <khem> yes please do
May 27 05:28:22 <khem> I dont have this problem here
May 27 06:06:39 <CIA-1> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * re1828041e6 10openembedded.git/recipes/openssl/ (openssl-1.0.0/configure-targets.patch openssl_1.0.0.bb): 
May 27 06:06:39 <CIA-1> openssl_1.0.0.bb: Update configure target patch to have correct number of colons (Bug 5429)
May 27 06:06:39 <CIA-1> * Use linux-uclibcebi for target OS on ARM uclibc.
May 27 06:06:39 <CIA-1> Signed-off-by: Khem Raj <raj.khem@gmail.com>
May 27 06:06:50 <CIA-1> 03João Henrique Freitas <joaohf@gmail.com> 07org.openembedded.dev * rd6608669e7 10openembedded.git/recipes/lksctp-tools/ (lksctp-tools.inc lksctp-tools_1.0.7.bb): 
May 27 06:06:50 <CIA-1> lksctp: Add recipes for lksctp tools
May 27 06:06:50 <CIA-1> Signed-off-by: João Henrique Freitas <joaohf@gmail.com>
May 27 06:06:50 <CIA-1> Signed-off-by: Khem Raj <raj.khem@gmail.com>
May 27 07:11:09 <CIA-1> 03sledz <sledz@ba11ecae-741b-462f-8724-1218f99f5906> 07org.openembedded.dev * rcf2bdb96eb 10openembedded.git/recipes/linux/linux-2.6.24/hipox/defconfig: 
May 27 07:11:09 <CIA-1> linux-2.6.24: enable ppp modules for hipox machine
May 27 07:11:09 <CIA-1> Signed-off-by: Steffen Sledz <sledz@dresearch.de>
May 27 07:13:23 <hrw> morning
May 27 07:29:11 <CIA-1> 03Steffen Sledz <sledz@dresearch.de> 07org.openembedded.dev * ra04c213a1a 10openembedded.git/recipes/jansson/ (jansson.inc jansson_1.2.1.bb): 
May 27 07:29:11 <CIA-1> jansson: new recipe
May 27 07:29:11 <CIA-1> Jansson is a C library for encoding, decoding and manipulating JSON data.
May 27 07:29:11 <CIA-1> Signed-off-by: Steffen Sledz <sledz@dresearch.de>
May 27 07:29:11 <CIA-1> Acked-by: Mario Schuknecht <m.schuknecht@dresearch.de>
May 27 07:32:16 <CIA-1> 03Steffen Sledz <sledz@dresearch.de> 07org.openembedded.dev * r816630f2b2 10openembedded.git/recipes/ntp/files/hipox/ (ntp.conf ntpd): 
May 27 07:32:16 <CIA-1> ntp: modified config for hipox machine
May 27 07:32:16 <CIA-1> * don't use externals NTP servers
May 27 07:32:16 <CIA-1> * use '-x' option to avoid forward time skips
May 27 07:32:16 <CIA-1> Signed-off-by: Steffen Sledz <sledz@dresearch.de>
May 27 07:34:41 <ant_work> morning
May 27 07:38:42 <ant_work> after last round of patches here dropbear now fails do_configure: ->   file://allow-nopw.patch;apply=no \  -> not found
May 27 07:48:04 <CIA-1> 03Roger Monk <r-monk@ti.com> 07org.openembedded.dev * r2ccbd56b86 10openembedded.git/recipes/angstrom/angstrom-uboot-scripts.bb: (log message trimmed)
May 27 07:48:04 <CIA-1> angstrom-uboot-scripts: Change installdir to /boot and rename configs
May 27 07:48:04 <CIA-1> * Install the scripts into /boot instead of datadir
May 27 07:48:04 <CIA-1> * Install the original .txt's files as well as .scr's so that users can
May 27 07:48:04 <CIA-1> use target mkimage to rebuild/modify/recreate
May 27 07:48:05 <CIA-1> * Rename configs for consistency
May 27 07:48:06 <CIA-1> Signed-off-by: Roger Monk <r-monk@ti.com>
May 27 08:01:04 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rf65670e47a 10openembedded.git/recipes/ti/ti-devshell.bb: ti-devshell: fix patch to TI stuff, spotted by Yaman Umuroglu
May 27 08:28:46 <jic23> Morning all.  Dumb question of the day.  Can anyone suggest why I'm getting no kernel modules installed in imote2-image?
May 27 08:28:59 <jic23> It's using the linux-zigbee git recipe.
May 27 08:29:23 <jic23> i'll admit I've never really understood how oe knows which modules to install.
May 27 08:32:57 <ao2> jic23, I have a IMAGE_INSTALL_append line in my machine conf to specify which kernel modules to install when creating an image, but this can be done at image level too of course.
May 27 08:34:25 <jic23> ao2, cool, I'll try that.
May 27 08:34:49 <jic23> I had thought the whole rrecomends stuff should pull in modules if they are available, but that's not working.
May 27 08:35:19 <ao2> kernel modules package have names like kernel-module-moto-usb-ipc that is kernel-module-${MODULE_NAME}
May 27 08:35:26 <ao2> packages*
May 27 08:35:35 <jic23> yup.  
May 27 08:36:56 <ao2> jic23,  there should be also something like kernel-module-all, but I don't recall if that's the exact name
May 27 08:38:24 <JaMa> iirc kernel-modules
May 27 08:48:37 <jic23> ao2 and JaMa, Thanks, that fixed it - could have sworn I tried that earlier!
May 27 08:49:37 <ao2> jic23, you're welcome
May 27 08:51:10 <ao2> hey people, here's a post about using the git fetcher with "protocol=file", I found that very useful: http://ao2.it/en/blog/2010/05/27/neat-compilerun-cycle-git-and-openembedded
May 27 08:52:03 <ao2> let me know if there is something incomplete/inaccurate/incorrect
May 27 09:04:41 <fraxinas> is raj here atm?
May 27 09:05:07 <fraxinas> aw ok i c he's away
May 27 09:27:03 <CIA-1> 03Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r7b6e5798eb 10openembedded.git/recipes/images/imote2-image.bb: 
May 27 09:27:03 <CIA-1> imote2-image: Remove ibrdtnd from the default install.
May 27 09:27:03 <CIA-1> Thinking about it twice it makes not much sense in the image. It is not needed
May 27 09:27:03 <CIA-1> for the board and people who are interested in delay tolerant networking can
May 27 09:27:03 <CIA-1> just install the package.
May 27 09:41:19 <jic23> aoe, looks good to me. That's pretty much how I do it.
May 27 09:41:29 <jic23> ao2 that is!
May 27 09:42:08 <jic23> and Stefan just fixed my other bug.  Today is proving successful.
May 27 09:54:15 <ant_work> bump: after last round of patches here dropbear now fails do_configure: ->   file://allow-nopw.patch;apply=no \  -> not found
May 27 09:54:29 <ant_work> kergoth is still afk...
May 27 09:57:59 <CMoH> ant_work, i'm stuck at the same error
May 27 09:58:03 <ant_work> I just spotted this this morning, no time to debug it until this evening...hopefully is recipe-issuel (patch -p1 fails)
May 27 09:58:35 <ant_work> if you are there pls check where the patch landed in WORKDIR
May 27 10:01:15 <CMoH> no, there's no such patch in workdir (if you're asking me, ant_work :D)
May 27 10:01:28 <ant_work> yea, thx
May 27 10:01:44 <ericben> ant_work: quick fix : DISTRO_TYPE=release ;-)
May 27 10:01:50 <ant_work> ;)
May 27 10:02:02 <ant_work> then we have an issue with   file://allow-nopw.patch;apply=no
May 27 10:02:15 <ant_work> yesterday apply=yes was changed...
May 27 10:02:36 <ant_work> su I suspect base.bbclass or patch.bbclass
May 27 10:03:48 <CMoH> well, i guess i'll just edit the file in the meantime
May 27 10:04:17 <ant_work> he he
May 27 10:05:08 <ant_work> pls let us know if this is the only recipe breaking after the last kergoth's cleanup
May 27 10:05:49 <jic23> is there an easy way of disabling parallel building for a particular recipe?
May 27 10:06:05 <jic23> (lowpan-tools fails currently due I think to a bork upstream)
May 27 10:06:12 <hrw> PARALLEL_MAKE = "" in recipe
May 27 10:06:24 <jic23> hrw, ah. I guess that was obvious
May 27 10:06:38 <CMoH> ok, ant_work
May 27 10:06:43 <CMoH> brb
May 27 10:10:25 <ant_work> ericben: btw, about psplash logo, wich size is it?
May 27 10:10:34 <ant_work> do we have vga and qvga?
May 27 10:11:06 <ericben> ant_work: only one (I think there was only one befor no ?)
May 27 10:11:30 <ericben> ant_work: size : 220x177
May 27 10:11:38 <ericben> fits well in a QVGA screen
May 27 10:12:01 <ant_work> I ask because I did 2 versions of it as kernel bootlogo
May 27 10:12:14 <ant_work> see path: root/recipes/kexecboot/files
May 27 10:12:29 <ericben> ant_work: ok, it would be possible to tine psplash recipe to generate the bootlogo depending on the screen size
May 27 10:13:10 <ant_work> I tried to have 'similar if not same' logos for kernel and bootsplash
May 27 10:13:19 <hrw> ericben: define screen size for whole arch?
May 27 10:13:30 <hrw> ericben: what about devices with video output?
May 27 10:13:32 <ericben> hrw: no for machine
May 27 10:13:51 <hrw> beagleboard looks different with 800x480/1024x768/1280x800 etc
May 27 10:13:58 <hrw> still one machine 
May 27 10:14:08 <ericben> hrw: yes but actually you have only one logo on beaghleboard ?
May 27 10:14:19 <ericben> which is the small one
May 27 10:14:34 <hrw> probably
May 27 10:14:39 <hrw> now I have ubuntu on bb
May 27 10:14:47 <ericben> so maybe we could have one for wvga and one for VGA which can be used for "bigscreen"
May 27 10:14:47 <woglinde> jo
May 27 10:14:55 <hrw> hi woglinde 
May 27 10:15:07 <ericben> hrw: last time I checked ubuntu on i.MX51 is was quite slow
May 27 10:15:23 <woglinde> ~seen zecke
May 27 10:15:24 <ibot> zecke <~ich@dsl-62-220-14-162.berlikomm.net> was last seen on IRC in channel #oe, 2d 2m 20s ago, saying: 'mckoan: is it quilt or patch?'.
May 27 10:15:28 <ericben> is it fast on BB ?
May 27 10:15:52 <ant_work> hi woglinde 
May 27 10:16:06 <hrw> ericben: I use it as headless for some experiments
May 27 10:16:20 <woglinde> hi ant
May 27 10:17:00 <ericben> hrw: ok I had a big screen connected : http://www.eukrea.com/en/news/101-122009-ubuntu-sur-imx515 ;-)
May 27 10:17:53 <woglinde> ericben maybee you had only xorg-fdev running
May 27 10:18:08 <woglinde> hi djwillis
May 27 10:18:15 <hrw> ericben: technically speaking I have 20" lcd with 1280x800 connected. but most of time turned off
May 27 10:18:55 <woglinde> damn musb error with bb
May 27 10:19:15 <woglinde> I cannt connect anything via usb to it
May 27 10:19:21 <woglinde> with the latest kernel
May 27 10:19:30 <ericben> woglinde: maybe I didn't spent some time to optimize it, I expect to integrate the accelerated drivers to OE soon, ubuntu is to big for what I need
May 27 10:19:44 <woglinde> right
May 27 10:19:50 <woglinde> to many deps
May 27 10:20:18 <ericben> hrw: here it was in 1280x1024 (when I said big screen, it was big resolution ;-)
May 27 10:21:19 <ericben> woglinde: yes and the parts provided by Freescale on their site are split in several places which don't makes it easy to use them and to use a customized kernel/config
May 27 10:21:34 <woglinde> ericben haha sounds like ti
May 27 10:22:28 <woglinde> okay lunch with zecke now
May 27 10:30:58 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * re9aacc4ce4 10openembedded.git/recipes/ (8 files in 2 dirs): 
May 27 10:30:58 <CIA-1> shr-apps: bump SRCREV of autorev packages
May 27 10:30:58 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 10:31:08 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * re70f21a140 10openembedded.git/recipes/openmoko-3rdparty/emtooth_svn.bb: 
May 27 10:31:08 <CIA-1> emtooth: bump SRCREV
May 27 10:31:08 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 10:31:10 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r892b0fc752 10openembedded.git/recipes/eglibc/eglibc_2.12.bb: 
May 27 10:31:10 <CIA-1> eglibc_2.12: add es_CR.ISO-8859-1 to GLIBC_BROKEN_LOCALES
May 27 10:31:10 <CIA-1> * details: http://sourceware.org/bugzilla/show_bug.cgi?id=11258
May 27 10:31:10 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 10:31:11 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rb3f4268d41 10openembedded.git/recipes/shr/phoneui-shr-theme-neo_git.bb: 
May 27 10:31:11 <CIA-1> phoneui-shr-theme-neo: bump SRCREV (fixed quick-settings theme)
May 27 10:31:12 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 10:31:12 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * ra8409e9153 10openembedded.git/recipes/shr/phoneui-shr-theme-o2_git.bb: 
May 27 10:31:13 <CIA-1> phoneui-shr-theme-o2: bump SRCREV (fixed quick-settings theme)
May 27 10:31:13 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 10:51:16 <melchior__> What the environment variables enaMonExt in u-boot is used for ?
May 27 11:03:18 <woglinde> re
May 27 11:04:39 <eFfeM_work> hi, anyone by any chance tried to bake gcc 4.1.2 (for any target) on ubuntu 10.04? I'm getting gcc-4.1/gcc/crtstuff.c:323: internal compiler error: Segmentation fault
May 27 11:06:34 <woglinde> effem where do you need gcc .41?
May 27 11:07:52 <eFfeM_work> woglinde: i'm trying to get the nios2 toolchain to build under oe, that toolchain is make with a 4.1.2-like gcc (from windriver, not exactly the 4.1.2 from gnu)
May 27 11:08:08 <woglinde> ieeehks
May 27 11:08:14 <eFfeM_work> wanted to get things working on 4.1.2 before I proceed to a newer version
May 27 11:09:09 <eFfeM_work> tried also to use it as an external toolchain in oe but failed miserably, bitbake helloworld or zip works but for soem reason with external toolchain bitbake bash or busybox still want to compile gcc-cross 
May 27 11:10:31 * eFfeM_work is open to any suggestion 
May 27 11:10:42 <woglinde> hi mickyl
May 27 11:10:46 <woglinde> hi coredump
May 27 11:12:04 <woglinde> eFfeM_work hm run bitbake -DDD and bitbake -g to see why bash or busybox not depends on external toolchain
May 27 11:12:25 <hrw> http://www.ouaza.com/wp/?p=271
May 27 11:12:30 <hrw> Raphaël Hertzog: Rewriting update-alternatives in C
May 27 11:13:42 <eFfeM_work> woglinde, did bitbake -g, this line didn't make me happy:
May 27 11:13:43 <eFfeM_work> "libgcc" [label="libgcc(gcc-cross) 0:4.3.3-r12.1\n/home/frans/workspace/nios2/openembedded.git/recipes/gcc/gcc-cross_4.3.3.bb"]
May 27 11:14:00 <eFfeM_work> that was with external toolchain
May 27 11:14:04 <eFfeM_work> hi GNUtoo|oeee
May 27 11:14:17 <JaMa> hrw: great news! u-a-cworth ie after upgrading busybox is quite slow :)
May 27 11:15:22 <GNUtoo|oeee> eFfeM_work, hi
May 27 11:15:28 <woglinde> eFfeM_work hm could you try libgcc_provided
May 27 11:15:39 <woglinde> hi gnutoo
May 27 11:18:12 * woglinde wonders why nobody packed libxvp yet
May 27 11:18:13 <eFfeM_work> woglinde, you mean ASSUME_PROVIDED += "libgcc" ? (or would that be virtual/libgcc) Or do I misunderstand you
May 27 11:19:49 <woglinde> effem yeah thats what I meant
May 27 11:20:29 <woglinde> hm you could grep recipes if it is virtual/ or purelibgcc
May 27 11:20:31 <eFfeM_work> ok, will try
May 27 11:20:35 <woglinde> dont know it offhand
May 27 11:23:48 <CMoH> satisfy_dependencies_for: Cannot satisfy the following dependencies for task-base:
May 27 11:23:49 <CMoH> |  *    alsa-utils-alsactl *    alsa-utils-alsamixer
May 27 11:24:18 <CMoH> anyone familiar with that?
May 27 11:24:57 <woglinde> hm either remove alsa-complet
May 27 11:25:07 <woglinde> or correct the dep
May 27 11:25:11 <woglinde> in the recipe
May 27 11:25:35 <woglinde> or try to add both packages to the image
May 27 11:26:01 <CMoH> i'll be needing alsa though
May 27 11:29:29 <eFfeM_work> woglinde: seems to improve things,let's see how far we get with that
May 27 11:32:58 <woglinde> yeah
May 27 11:35:17 <CMoH> i don't get it - how would the alsa-utils-alsactl dep be satisfied ?
May 27 11:35:59 <woglinde> cmoh look if there is a recipe or packge for it
May 27 11:36:00 <CMoH> i mean there is an alsa-utils package, but no alsa-utils-alsactl
May 27 11:36:23 <CMoH> the alsa-utils package does build FILES_alsa-utils-alsactl     = "${sbindir}/alsactl"
May 27 11:36:34 <woglinde> yes
May 27 11:36:50 <CMoH> the reason i'm asking is that a simple grep through recipes provides a whole list of recipes using this dep
May 27 11:39:18 <CMoH> woglinde, what should i do then? make alsa-utils PROVIDE alsa-utils-alsactl? 
May 27 11:41:04 <woglinde> cmoh is there no line PACKAGES += "alsa-utils-alsactl" ?
May 27 11:41:07 <eFfeM_work> woglinde: added ASSUME_PROVIDED for libgcc and a few friends, still bitbake -g says it wants to build gcc-cross-initial and gcc-cross-intermediate (but not gcc-cross). no idea why, there is no package in depends.dot that has something with gcc-cross* at the right side of the ->
May 27 11:41:22 <woglinde> effem strange
May 27 11:42:00 <CMoH> woglinde, there is that in the alsa-utils recipe
May 27 11:42:25 <eFfeM_work> woglinde:  see http://www.pastie.org/979717
May 27 11:44:17 <eFfeM_work> and I already have  virtual/${TARGET_PREFIX}gcc-cross-initial virtual/gcc-cross-initial gcc-cross-initial in ASSUME_PROVIDED
May 27 11:44:26 <eFfeM_work> at this stage better have too much in it than too little
May 27 11:44:36 <woglinde> right
May 27 11:46:33 <woglinde> re ericben
May 27 11:46:57 <ericben> re woglinde
May 27 11:48:04 <eFfeM_work> trying to build 4.1.2 for beagleboard now, to find out if it is an issue with gcc or with my machine (or the nios changes I have)
May 27 12:39:40 <CIA-1> 03Roger Monk <r-monk@ti.com> 07org.openembedded.dev * r9b6418d9f3 10openembedded.git/recipes/angstrom/angstrom-uboot-scripts/linuxtagdemo.cmd: 
May 27 12:39:40 <CIA-1> angstrom-uboot-scripts: Add linuxtag demo script
May 27 12:39:40 <CIA-1> Signed-off-by: Roger Monk <r-monk@ti.com>
May 27 12:39:40 <CIA-1> Signed-off-by: Koen Kooi <k-kooi@ti.com>
May 27 12:41:52 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rea69e240f8 10openembedded.git/recipes/shr/elementary-theme-gry_git.bb: 
May 27 12:41:52 <CIA-1> elementary-theme-gry: bump SRCREV (fixed #1115)
May 27 12:41:52 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 13:18:45 <melchior__> i'm trying to use a debian nfs rootfs with my custom kernel. At first i had unable to open initial console problem, that i resolved by creating the node ttyS0 but now, after the routt file system has been mounted i get error 'nfs: server 192.168.0.2 not responding, still trying'. What could that be ?
May 27 13:21:11 <CMoH-notebook> another quick question: how can i control the cxxflags and the cflags globally for a bitbake run?
May 27 13:33:54 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r7ce6d567e4 10openembedded.git/recipes/xinput-calibrator/ (4 files in 3 dirs): 
May 27 13:33:54 <CIA-1> xinput-calibrator: add pointercal.xinput data for om-gta02 and install it by default
May 27 13:33:54 <CIA-1> * is there someone else then SHR using xinput_calibrator_once.sh in
May 27 13:33:54 <CIA-1> Xsession.d? Then you should provide valid pointercal.xinput for your
May 27 13:33:54 <CIA-1> devices.
May 27 13:33:55 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 13:34:03 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rfa32ebe810 10openembedded.git/recipes/xserver-common/ (2 files in 2 dirs): 
May 27 13:34:03 <CIA-1> xserver-common: use only xinput_calibrator for calibration (used only for SHR)
May 27 13:34:03 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 13:54:12 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r53d71738a2 10openembedded.git/recipes/mesa/ (mesa-dri-7.8.1/glamo.patch mesa-dri_7.8.1.bb): 
May 27 13:54:12 <CIA-1> mesa-dri_7.8.1: update glamo patch a bit
May 27 13:54:12 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 13:54:22 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * re04e059b26 10openembedded.git/recipes/xorg-driver/xf86-video-glamo_git.bb: 
May 27 13:54:22 <CIA-1> xf86-video-glamo: bump SRCREV for newer libdrm compatibility
May 27 13:54:22 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 13:54:23 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r00d250c39a 10openembedded.git/recipes/dri/glamo-dri-tests_git.bb: 
May 27 13:54:23 <CIA-1> glamo-dri-tests: bump SRCREV for newer libdrm compatibility
May 27 13:54:23 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 13:54:24 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rc6c42567d9 10openembedded.git/recipes/dri/libdrm_git.bb: 
May 27 13:54:24 <CIA-1> libdrm_git: bump SRCREV for 2.4.20
May 27 13:54:25 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 15:16:57 <jconnolly> hi all.  i had a question for people working professionally with SD-based rootfs's
May 27 15:17:12 <jconnolly> i work for bug labs and we've had trouble finding a company to program our SD cards in any volume
May 27 15:17:40 <jconnolly> we used a company a while ago but they would send us back FAT16-formatted cards with /bug-image-production.ext3 residing on the card
May 27 15:17:50 <jconnolly> anyone have suggestions or prior experience with a reliable company?
May 27 15:17:58 <jconnolly> we've been doing it in house but obviously it doesn't scale
May 27 15:34:04 <Crofton|work> jconnolly, I'll ask a friend
May 27 15:38:41 <hrw> hi JC
May 27 15:41:19 <jconnolly> Crofton|work: much obliged
May 27 15:41:22 <jconnolly> hi hrw 
May 27 15:44:39 <hoj> Hi. Trying to build boost for omap3530, bitbake wants first to build libxt. How can I find where this dependency is?  I generated .dot files from bitbake for boost, but libxt does not show up.
May 27 16:20:44 <mwester-laptop>  bitbake -g (or similar, check the help text from bitbake)
May 27 16:22:40 <kergoth_> anyone recall if we still have the original wiki pages from the original oe brainstorming sessions?
May 27 16:22:44 <kergoth_> in a backup somewhere, perhaps?
May 27 16:23:34 <kergoth_> cbrake: ping
May 27 16:28:28 <hoj> mwester-laptop: Thanks for the suggestion.  I tried bitbake -g but the resulting .dot files contain no libxt
May 27 16:42:50 <denix> hoj: libxt PROVIDES xt, but still you should see it in .dot files - grep libxt *.dot
May 27 16:43:46 <hoj> denix: grep libxt *.dot | wc -l   = 0    I have very old bitbake; woudl that matter?
May 27 16:49:53 <denix> hoj: it shouldn't. let me try...
May 27 16:58:38 <denix> hoj: bitbake boost -g; grep libxt *.dot|wc -l = 164
May 27 16:58:58 <denix> hoj: depends.dot:"tk" -> "libxt"
May 27 16:59:36 <denix> BitBake Build Tool Core version 1.8.19, bitbake version 1.8.19
May 27 17:01:22 <hoj> denix: thanks for trying that.  Must be old recipe files or some other change I never picked up.  I'll try again in newer sources.
May 27 17:07:06 <IgorK> good morning
May 27 17:07:39 <IgorK> can someone please look at this compilation failure: http://pastebin.com/J5r6RmAP
May 27 17:10:22 <hoj> denix: updated arago tree gives better results. Thanks
May 27 17:10:40 <denix> hoj: welcome :)
May 27 17:21:19 <cbrake> kergoth_: hello
May 27 17:25:45 <kergoth_> cbrake: i was wondering if you happened to recall whatever happened to the really, really old wiki content.  specifically, i'm wondering if we still have the original wiki pages where the brainstorming about the original design of oe were done
May 27 17:25:52 <kergoth_> or if you knew who might know 
May 27 17:26:17 <cbrake> kergoth_: koen was the one who switched from the really old wiki to drupal
May 27 17:26:22 <kergoth_> ah, okay, thanks
May 27 17:26:45 <kergoth_> i'm looking to try writing up some background / history and perhaps some high level conceptual info on oe that i haven't seen written down in many places
May 27 17:26:49 <cbrake> kergoth_: I seem to recall it got pulled out from under us for some reason, so not sure if he has a copy of the content
May 27 17:26:51 * kergoth_ needs to practice his writing anyway
May 27 17:26:55 <kergoth_> hmm, okay
May 27 17:27:13 <kergoth_> well, i can probably remember most of it, but i'll check with koen
May 27 17:28:52 <IgorK> anyone? gpe-mixer can't be compiled....
May 27 17:29:24 <kergoth_> cbrake: do you recall the irc channel he's usually in, offhand?
May 27 17:29:26 * kergoth_ alays forgets
May 27 17:30:28 <cbrake> kergoth_: try #beagle
May 27 17:32:02 <wroberts1> i get build failure of dropbear_0.51 because allow-nopw.patch No such file or directory
May 27 17:32:19 <denix> wroberts1: check ML
May 27 17:37:57 <wroberts1> denix: devel, commits, issues, users,...?
May 27 17:38:30 <kergoth> cbrake: koen says we had a backup when we were on linuxtogo, so i wonder what happenedt o it when we moved from there
May 27 17:40:37 <kergoth> though, he says the really really old stuff was on hh.o.. 
May 27 17:40:41 * kergoth rolls eyes
May 27 17:47:49 <kergoth> meh
May 27 17:48:12 <wroberts1> i have openembedded/recipes/dropbear/allow-nopw.patch, but it seems do_configure wants it to be in <oetmp>//work/armv5te-angstrom-linux-gnueabi/dropbear-0.51-r1.01
May 27 17:48:16 <kergoth> think the info i wanted is either gone entirely, or on hh.o's machine
May 27 17:48:17 <kergoth> heh
May 27 17:58:09 <khem> wroberts1: apply this patch http://patchwork.openembedded.org/patch/2106/ and http://patchwork.openembedded.org/patch/2104/
May 27 17:58:33 <khem> and http://patchwork.openembedded.org/patch/2105/
May 27 17:58:39 <khem> good morning all
May 27 17:59:03 <denix> http://thread.gmane.org/gmane.comp.handhelds.openembedded/32984/focus=32989
May 27 18:00:15 <denix> wroberts1: google is your friend :)
May 27 18:00:53 <khem> Hi denix 
May 27 18:01:35 <khem> JaMa: around ?
May 27 18:01:39 <denix> khem: gm
May 27 18:02:01 <khem> JaMa: I have figured out the gcc bug while compiling kernel 2.6.34 
May 27 18:02:12 <khem> JaMa: its underwork to fix gcc
May 27 18:03:08 <khem> meanwhile you can add a workaround and test if you want to the workaround is to add -fno-ipa-sra option to gcc you can use append it to FULL_OPTIMIZATION var 
May 27 18:04:12 <khem> denix: where in US are you ?
May 27 18:04:23 <denix> khem: DC area
May 27 18:04:34 <khem> its been raining in nothern CA 
May 27 18:04:38 <khem> this whole week
May 27 18:05:14 <khem> one I am happy that I dont have to water the plants and garden but sad that I have to mow it often
May 27 18:05:45 <denix> I didn't know rains are possible in the Valley... :)
May 27 18:06:19 <khem> yeah this year its been raining since december
May 27 18:06:55 <khem> denix: how is DC I was there in 2007 summer 
May 27 18:06:59 <khem> its nice in summer
May 27 18:07:01 <JaMa> khem: great news, should I rebuild everything, or just kernel for test?
May 27 18:07:13 <khem> JaMa: try kernel only first
May 27 18:07:17 <JaMa> ok
May 27 18:07:30 <khem> it should boot a root file system built with 4.4.4 ok
May 27 18:08:05 <denix> khem: usually too humid in the summer here
May 27 18:08:13 <khem> denix: thats right
May 27 18:08:15 <denix> feels like a sauna :)
May 27 18:08:20 <khem> heh
May 27 18:09:58 <denix> but this year's spring wasn't too hot, sometimes even cold, which is unusual for the area
May 27 18:10:30 <khem> yeah I have my sweater on and its beginning of June
May 27 18:10:50 <denix> we just got hot weather (mid 90s F) few days back, which is 1-2 months later than usual :)
May 27 18:10:55 <denix> global warming? :)
May 27 18:11:07 <khem> yeah :)
May 27 18:11:27 <khem> I think the fluctuations are high
May 27 18:11:45 <khem> it varies from 55 to 80 here in couple of days
May 27 18:12:47 <denix> right, same here
May 27 18:13:12 <khem> denix: do you work out of home ?
May 27 18:15:49 <IgorK> any suggestions on fixing gpe-mixer.patch  so it become unified? anybody?
May 27 18:16:03 <khem> hello pb_ 
May 27 18:17:25 <khem> pb_: I would like to create separate staging for intermediate gcc and glibc steps in order to avoid the sysroot conflicts do you think its ok approach
May 27 18:19:06 <khem> IgorK: whats wrong with gpe-mixer.patch
May 27 18:19:07 <denix> khem: sometimes, not right now
May 27 18:20:14 <IgorK> khem: http://pastebin.com/J5r6RmAP
May 27 18:22:26 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r475aedbc9b 10openembedded.git/recipes/dri/libdrm_2.4.18.bb: 
May 27 18:22:27 <CIA-1> libdrm_2.4.18: add missing dependency libpthread-stubs
May 27 18:22:27 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 27 18:26:51 <khem> IgorK: it works ok here
May 27 18:27:00 <khem> IgorK: I would say clean it and rebuild 
May 27 18:27:16 <khem> bitbake -b gpe-mixer_0.42.bb -c clean
May 27 18:27:20 <khem> bitbake -b gpe-mixer_0.42.bb -c patch
May 27 18:27:25 <khem> see if that works
May 27 18:27:47 <khem> IgorK: btw. it will be good if you updated to latest
May 27 18:29:13 <JaMa> vim-7.2 also seems still broken after last .patch .diff changes (;apply=no is used there), seen some patch on ML about it
May 27 18:30:33 <kergoth_> khem fixed that yesterday
May 27 18:31:00 <khem> Hi kergoth_ 
May 27 18:31:06 <JaMa> I'm pretty sure I have HEAD and it's broken again
May 27 18:31:20 <khem> kergoth_: hmmm the patches are now in WORKDIR too
May 27 18:31:53 <khem> kergoth: may be quilt should be using it from workdir and not creating a patches dir as it does
May 27 18:32:18 <khem> kergoth_: that will be good because sometime some packages have patches as a sourcedir
May 27 18:32:24 <kergoth_> well, there's a patch on the list to fix an issue with unpacked patches combined with apply=no
May 27 18:33:10 <kergoth_> khem: personally, i think we could drop quilt entirely as our default patch application method.  it's only really useful when debugging or developing, and you can set PATCHTOOL yourself to override it in that case
May 27 18:34:50 <khem> kergoth: I would do the opposite i.e. set PATCHTOOL to something else if we are not developing and only doing build and release
May 27 18:35:04 <khem> but thats a developer's hat
May 27 18:35:16 <kergoth_> pretty sure quilt also takes longer to apply them
May 27 18:35:21 <kergoth_> since it backs up all the files at each patch
May 27 18:35:23 <khem> putting on user's hat I think I would say I dont care
May 27 18:36:08 <kergoth_> should profile it
May 27 18:36:11 <khem> kergoth: although it would be cool if we could use PATCHTOOL like DISTRO or MACHINE
May 27 18:36:19 <khem> in that case it will be good mix
May 27 18:36:29 <kergoth_> its just another variable
May 27 18:36:38 <khem> i.e. as a developer I can start of my build with PATCHTOOL being patch
May 27 18:36:41 <kergoth_> you can
May 27 18:36:58 <kergoth_> if the recipe sets it, it'll override you, of course, unless you set PATCHTOOL_local or something
May 27 18:37:02 <kergoth_> but it works fine
May 27 18:37:07 <khem> kergoth_: cool so it wont reparse again the whole thing ?
May 27 18:37:19 <kergoth_> ?
May 27 18:37:26 <kergoth_> if its in a .conf, of course it reparses
May 27 18:38:13 <kergoth_> the parse cache is only used to store package name, version, and dependency information for the runqueue generation
May 27 18:38:17 <kergoth_> + provides, etc of course
May 27 18:38:29 <kergoth_> any other variable could almsot certainly be switched to an env var with extrawhite safely
May 27 18:38:36 <khem> kergoth_: say I was building a console image with default patchtool which was say patch. Now it breaks in vim and I want to debug why vim compile failed so now I would clean vim and the want to use quilt as patchtool and workout a patch for vim
May 27 18:38:37 <kergoth_> (as long as that var isnt' used indirectly in those)
May 27 18:38:47 <IgorK> khem: same error
May 27 18:38:53 <kergoth_> you could do patchtool via the environemtn with BB_ENV_EXTRAWHITE
May 27 18:38:55 <kergoth_> or you could use amend.inc
May 27 18:39:04 <kergoth_> which lets you amend to recipes, so only that recipe would be reparsed
May 27 18:39:29 <khem> kergoth_: yeah BB_ENV_EXTRAWHITE should be fine
May 27 18:39:37 <khem> so you have my ack for it :)
May 27 18:39:49 * kergoth_ 'll have to experiment with it first :)
May 27 18:40:17 <khem> but still it would be nice if  quilt used WORKDIR for patches
May 27 18:40:18 <khem> may be
May 27 18:40:53 <khem> IgorK: do you have a ~/.quiltrc
May 27 18:41:11 <kergoth_> would be nice to make it apply a patch from an external location without storing it locally in patches at all
May 27 18:41:21 <khem> even better
May 27 18:41:22 <kergoth_> then it could apply them directly from their file:// location 
May 27 18:42:07 <khem> and yeah when I do quilt new then the patch could be created in FILESPATH too
May 27 18:42:40 <khem> and quilt add would also mean git add :)
May 27 18:43:00 <khem> and another script would append it to SRC_URI :)
May 27 18:44:08 <khem> QUILT_PATCHES var can be used to set patches dir to whatever we want
May 27 18:44:10 <kergoth_> hehe
May 27 18:44:12 <kergoth_> thatd be cute
May 27 18:44:16 <kergoth_> hmm
May 27 18:45:14 <khem> problem is when it collects patches from more than one location
May 27 18:45:52 <khem> Well we could use relative paths in series file prolly
May 27 19:21:01 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rc9362d96d7 10openembedded.git/recipes/dri/glamo-dri-tests_git.bb: glamo-dri-tests: bump SRCREV a bit more
May 27 19:25:42 <CIA-1> 03Michael 'Mickey' Lauer <mickey@vanille-media.de> 07org.openembedded.dev * rc69ff6d9c0 10openembedded.git/recipes/htcdream/htcdream-gps_git.bb: htcdream-gps: new recipe; gps test program for the HTC Dream
May 27 19:26:59 <mickey|zzZZzz> GNUtoo: please try with this recipe
May 27 19:27:13 <mickey|zzZZzz> GNUtoo: if that works, i'll create an fsodeviced plugin 
May 27 19:27:28 <GNUtoo> ok I'll have to install something and then I'll do that
May 27 19:27:31 <GNUtoo> thanks a lot!!!
May 27 19:46:18 <CIA-1> 03Enrico Scholz <enrico.scholz@sigma-chemnitz.de> 07org.openembedded.dev * r311bed0b40 10openembedded.git/classes/packaged-staging.bbclass: (log message trimmed)
May 27 19:46:18 <CIA-1> packaged-staging.bbclass: added missing space in find call
May 27 19:46:18 <CIA-1> Old find statement failed with something like
May 27 19:46:18 <CIA-1> $ find . \( -name XXX\)
May 27 19:46:18 <CIA-1> find: invalid expression; I was expecting to find a ')' somewhere but did not see one.
May 27 19:46:19 <CIA-1> Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
May 27 19:46:20 <CIA-1> Acked-by: Chris Larson <clarson@kergoth.com>
May 27 19:55:12 <woglinde> re effem
May 27 19:57:11 <CIA-1> 03Enrico Scholz <enrico.scholz@sigma-chemnitz.de> 07org.openembedded.dev * r0d270547fd 10openembedded.git/lib/oe/utils.py: (log message trimmed)
May 27 19:57:11 <CIA-1> oe.utils: added param_bool() method
May 27 19:57:11 <CIA-1> This new function works like dict's get() method but converts the
May 27 19:57:11 <CIA-1> returned value to a boolean.
May 27 19:57:11 <CIA-1> It is to be used to interpret e.g. 'apply=yes' parameters in SRC_URI.
May 27 19:57:12 <CIA-1> Moved from base.bbclass into lib/oe/utils.py -kergoth
May 27 19:57:13 <CIA-1> Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
May 27 19:57:14 <CIA-1> 03Enrico Scholz <enrico.scholz@sigma-chemnitz.de> 07org.openembedded.dev * r7cb990de93 10openembedded.git/classes/patch.bbclass: 
May 27 19:57:14 <CIA-1> patch.bbclass: use param_bool()
May 27 19:57:14 <CIA-1> This patch replaces a complicated if statement with a more simple
May 27 19:57:15 <CIA-1> code.
May 27 19:57:15 <CIA-1> Slightly altered to use oe.utils -kergoth
May 27 19:57:16 <CIA-1> Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
May 27 19:57:16 <CIA-1> Signed-off-by: Chris Larson <chris_larson@mentor.com>
May 27 19:57:17 <CIA-1> 03Enrico Scholz <enrico.scholz@sigma-chemnitz.de> 07org.openembedded.dev * reb8ad2af3a 10openembedded.git/classes/base.bbclass: (log message trimmed)
May 27 19:57:17 <CIA-1> base.bbclass: fixed 'apply=no' behavior
May 27 19:57:53 <CIA-1> This patch evaluates content of 'apply' parameter and copies files to
May 27 19:57:54 <CIA-1> workdir when it is not a patch or the parameter is false.
May 27 19:58:22 <JaMa> ensc: thanks
May 27 20:01:17 <ensc> CIA-1: my patch.bbclass changes are broken and the other two need rework (moving into util.bbclass or lib/oe)
May 27 20:01:26 <ensc> did not had time to change them
May 27 20:01:43 <ensc> eeek.. that's a bot :(
May 27 20:02:24 <kergoth_> broken? how so?
May 27 20:02:38 <kergoth_> already moved them into lib/oe/utils.py and adjusted the other two to use it
May 27 20:02:45 <kergoth_> if there's a bug in the function, let me know
May 27 20:03:00 <kergoth_> and yes, CIA reports commits pushed to the repository
May 27 20:03:03 * kergoth_ hugs CIA-1 
May 27 20:03:04 * CIA-1 hugs kergoth_
May 27 20:03:24 * denix slaps CIA-1
May 27 20:03:27 <ensc> kergoth_: it fails on stuff like file://foo.patch.gz
May 27 20:03:45 <kergoth_> oh, you didn't bring the extension mangling over into the function
May 27 20:04:08 * kergoth_ was quite careful to test nearly all the cases when he made the original change, but must've missed one when he adjusted unpack.bbclass
May 27 20:04:19 * kergoth_ grumbles
May 27 20:05:04 <kergoth_> er.. hmm
May 27 20:05:16 <ensc> wait...https://www.cvg.de/people/ensc/x.patch
May 27 20:05:35 <kergoth_> what's broken about that?
May 27 20:05:38 <ensc> would be my new patch but I did not tested it yet
May 27 20:05:46 * kergoth_ looks
May 27 20:05:57 <eFfeM> hi woglinde, all
May 27 20:06:24 <kergoth_> ensc: that damned logic has way too many variations
May 27 20:06:29 <kergoth_> it hurt my head getting it the way it was originally
May 27 20:06:34 <kergoth_> heh
May 27 20:06:42 <kergoth_> this is why we need actual unit tests
May 27 20:06:48 <ensc> yes
May 27 20:07:15 <ensc> I built a complex image with that new version and it suceeded
May 27 20:07:31 <denix> ensc: btw, do you have commit rights?
May 27 20:07:38 <ensc> denix: no
May 27 20:07:56 <denix> cbrake: ping
May 27 20:08:18 <cbrake> denix: 
May 27 20:08:22 <cbrake> denix: yes
May 27 20:10:39 <kergoth_> ensc: pretty sure teh logic in base.bbclass did function properly, so i'm going to revert and leave that alone for the time being, and adjust the unpack function to check for if not patch in parm and apply != 'yes'
May 27 20:10:46 <kergoth_> that should take care of it, as far as i can tell
May 27 20:10:52 <denix> cbrake: I thought someone already proposed to give ensc commit rights, but I maybe mistaken...
May 27 20:10:54 <kergoth_> can then start putting together unit tests to validate
May 27 20:11:15 <ensc> kergoth_: no, base.bbclass was broken  (in 'apply=no' case)
May 27 20:11:31 <kergoth_> worked fine in all my tests
May 27 20:11:34 <kergoth_> which case was broken?
May 27 20:11:40 <JaMa> vim-7.2
May 27 20:11:40 <cbrake> denix: could have slipped through the cracks -- are there any messages in oe-dev?
May 27 20:11:43 <kergoth_> er, i mispoke
May 27 20:11:46 <ensc> it broke dropbear (the nopw patch)
May 27 20:11:47 <kergoth_> i meant the patch.bbclass changes were fine
May 27 20:13:01 <ensc> kergoth_: the old version (without my patch) was ok.  But I wanted to remove the code duplication (interpretation of 'apply=XXX') with my patch
May 27 20:13:10 <kergoth_> i agree
May 27 20:13:20 <kergoth_> but i think we should make unit tests before making further changes
May 27 20:14:23 <CIA-1> 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * r5ff088e9df 10openembedded.git/classes/base.bbclass: 
May 27 20:14:23 <CIA-1> base.bbclass: fix issue with unpack of patches with apply=no
May 27 20:14:23 <CIA-1> Signed-off-by: Chris Larson <chris_larson@mentor.com>
May 27 20:14:25 <CIA-1> 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * rac5931ec67 10openembedded.git/classes/base.bbclass: 
May 27 20:14:25 <CIA-1> Revert "base.bbclass: fixed 'apply=no' behavior"
May 27 20:14:25 <CIA-1> This reverts commit eb8ad2af3a59dc7b4c64814815fc13977efaec6b.
May 27 20:14:26 <CIA-1> 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * r8c04a982e9 10openembedded.git/classes/patch.bbclass: 
May 27 20:14:26 <CIA-1> Revert "patch.bbclass: use param_bool()"
May 27 20:14:26 <CIA-1> This reverts commit 7cb990de933f22331cd701ecb45d1e30dd8f3c11.
May 27 20:14:45 <kergoth_> i left the param_bool function in lib/oe/utils, just reverted the use of it for the time being
May 27 20:16:40 <ensc> denix: yes; Tom Rini wanted to bring me in (15.04.2010)
May 27 20:19:21 <denix> ensc: was it on the mailing list? trying to find it...
May 27 20:19:41 <khem> denix: I think ant reported it on IRC
May 27 20:21:29 <ensc> denix: http://article.gmane.org/gmane.comp.handhelds.openembedded/31985
May 27 20:22:09 <IgorK> khem: ls: cannot access /home/arm/.qui*: No such file or directory
May 27 20:22:28 <khem> IgorK: whats your distro on host
May 27 20:22:34 <IgorK> do I have to have it in order to apply non-unified patches?
May 27 20:22:42 <IgorK> Gentoo
May 27 20:23:24 <khem> IgorK: It applies fine here
May 27 20:23:33 <khem> I use ubuntu 10.04
May 27 20:23:52 <khem> so I dont know what the problem really is on your end unless I can reproduce it
May 27 20:24:03 <khem> btw. hmmm 
May 27 20:24:11 <khem> which quilt is it using
May 27 20:24:25 <khem> do you have quilt in your build sysroot 
May 27 20:24:38 <khem> iow did it install quilt native
May 27 20:38:51 <IgorK> khem: http://pastebin.com/BNQPQ462
May 27 20:44:03 <khem> IgorK: I am using 0.48 here
May 27 20:44:11 <khem> IgorK: thats the difference
May 27 20:45:08 <IgorK> so the best is to do "git pull" from the main OE directory, right?
May 27 20:46:20 <khem> IgorK: do you have 0.46 in PREFERRED_VERSION in you local.conf ?
May 27 20:46:49 <khem> IgorK: before that I want to find out why 0.46 is being pulled in 
May 27 20:47:26 <khem> paste your local.conf
May 27 20:54:23 <IgorK> khem: here we go: http://pastebin.com/dYVsADRG
May 27 20:57:34 <woglinde> re pb
May 27 20:57:38 <khem> IgorK: hmm are you using org.openemededded.dev branch or something else
May 27 20:59:16 <khem> IgorK: btw TARGET_OS = "linux" is not needed in your local.conf
May 27 21:01:41 <khem> woglinde: hody
May 27 21:01:51 <khem> insert w somewhere
May 27 21:02:12 <woglinde> *g*
May 27 21:05:26 <IgorK> khem: Im using git tree of mini2440 device: git://repo.or.cz/openembedded/mini2440.git
May 27 21:05:42 <JaMa> khem: tried kernel with that flag.. but now it complains about missing init, but init is there (sysvinit), I'll try to rebuild whole image with that flag if it changes
May 27 21:07:51 <IgorK> and using this instructions: http://www.electronics.diycinema.co.uk/embedded/mini2440/bitbaking-the-kernel-angstrom-and-qt4-embedded-all-at-once/
May 27 21:11:49 <khem> IgorK: is it tracking .dev I have no clue what that repo is
May 27 21:12:09 <khem> JaMa: missing init ?
May 27 21:12:22 <JaMa> khem: like missing /sbin/init
May 27 21:12:27 <khem> JaMa: hmmm
May 27 21:12:34 <khem> JaMa: 2.6.34 ?
May 27 21:12:51 <JaMa> khem: http://paste.pocoo.org/show/219088/
May 27 21:13:08 <JaMa> yes 2.6.34, eglibc-2.12, gcc-4.5.0 etc
May 27 21:14:11 <khem> JaMa: and same setup works otherwise ?
May 27 21:14:26 <khem> you sure the commandline has init=/sbin/init in it
May 27 21:14:30 <JaMa> same except gcc version
May 27 21:15:13 <khem> JaMa: hmm thats strange
May 27 21:15:19 <khem> I did not run into that 
May 27 21:15:45 <JaMa> khem: maybe it's faulty uSD...
May 27 21:15:49 <khem> JaMa: did you patch makefile to add this option
May 27 21:16:31 <JaMa> khem: because even after mkfs I had to untar new image to different partition because the one I used for gcc-4.5 tests before always ended with IO errors
May 27 21:16:44 <JaMa> khem: which makefile?
May 27 21:17:14 <khem> kernel makefule
May 27 21:17:18 <khem> makefile
May 27 21:18:20 <IgorK> khem: I would say yes, but not sure. the person to ask would be florian, but he is not here @ the moment
May 27 21:19:28 <JaMa> khem: no, but I'm using kexecboot, mmt checking serial output
May 27 21:22:31 <IgorK> anyway to check if it is?
May 27 21:24:10 <woglinde> hi florian
May 27 21:26:53 <woglinde> re ant
May 27 21:27:20 <ant__> hey
May 27 21:28:09 <ant__> pb_: hello there
May 27 21:34:58 <IgorK> florian: is git://repo.or.cz/openembedded/mini2440.git tracking .dev?
May 27 21:35:08 <khem> JaMa: your setup is different
May 27 21:38:05 <GNUtoo> mickey|zzZZzz, 2 things on gps:
May 27 21:38:26 <GNUtoo> 1)be able to kill the program in order to stop gps
May 27 21:38:44 <GNUtoo> 2)change /dev/oncrpc/3000005b:90380d3d to /dev/3000005b:90380d3d:
May 27 21:38:47 <IgorK> khem: FYI - this repo is for mini2440 computer based on the Samsung S3C2440 chip
May 27 21:38:47 <khem> IgorK: alright this explains it http://repo.or.cz/w/openembedded/mini2440.git/tree/HEAD:/recipes/quilt
May 27 21:38:58 <khem> IgorK: its a weird fork 
May 27 21:39:13 <khem> unless its merged upstream OE you wont find much support in this channel
May 27 21:39:16 <GNUtoo> mickey|zzZZzz, ifyou're there let's talk in #openmoko-cdevel
May 27 21:39:23 <khem> because not many devs might be using it
May 27 21:39:39 <IgorK> :(
May 27 21:39:50 <khem> IgorK: you should always mention what repo/branch you are using
May 27 21:40:01 <khem> so to set expectations right
May 27 21:40:17 <IgorK> OK, will do
May 27 21:40:29 <IgorK> So what do u suggest?
May 27 21:41:26 <khem> whatever you prefer. you can fix that repo with whatever problems you encounter or promote the changes it has into upstream oe
May 27 21:42:13 <khem> many times such forks are done to maintain a given thing and you cant stretch it too much 
May 27 21:42:25 <khem> like it may be good for a given machine and given image
May 27 21:42:38 <khem> but if you try to play around it might break
May 27 21:42:59 <khem> best is to ask the maintainer of that fork what the plans are
May 27 21:43:45 <IgorK> ok, will do, thx
May 27 21:52:31 <ant__> khem: about that udev_151 hack for kernels <2.6.27
May 27 21:53:00 <ant__> some packaging doubts
May 27 21:53:22 <ant__> first: where to pull in the udev-static dependency
May 27 21:54:03 <ant__> second: why are udevadm and udevd packaged in dbg _?
May 27 21:54:18 <ant__> (thats' for udev-static_124)
May 27 21:55:21 <pb_> hi ant__ 
May 27 21:56:21 <ant__> khem: I understand we don't want to overwrite the 151 files, just a parallel installation
May 27 21:56:38 <ant__> but how to do it properly?
May 27 21:58:49 <ant__> basically udev-static doesn't seem to package anything :/
May 27 22:01:39 <mickey|zzZZzz> GNUtoo: 2) ok, will do that. 1) what should be executed on SIGTERM?
May 27 22:01:44 <mickey|zzZZzz> i.e. how do i turn it off?
May 27 22:02:04 <GNUtoo> mickey|zzZZzz, where did you took the sources from?
May 27 22:02:17 <mickey|zzZZzz> GNUtoo: your tarball
May 27 22:02:43 <GNUtoo> it seem not the same that I have
May 27 22:02:54 <GNUtoo> did you modify the sources?
May 27 22:04:22 <mickey|zzZZzz> just removed some bogus includes and added some more to make it compile
May 27 22:05:41 <mickey|zzZZzz> -> #openmoko-cdevel
May 27 22:05:58 <GNUtoo> ok
May 27 22:08:37 <khem> ant__: hmm let me check
May 27 22:09:01 <ant__> see logs on screen about files installed
May 27 22:11:07 <ant__> I think is do_install
May 27 22:11:45 <khem> ant__: udevadm should be in udev-utils
May 27 22:12:13 <ant__> hm.. I see it in workdir after do_compile
May 27 22:12:22 <ant__> NOTE:   /sbin/.debug/udevd-124-static
May 27 22:12:23 <ant__> NOTE:   /sbin/.debug/udevadm-124-static
May 27 22:12:24 <ant__> ^^
May 27 22:12:27 <ant__> ??
May 27 22:13:03 <khem> see packages-split/
May 27 22:13:10 <ant__> but we set  PACKAGES = "${PN}"
May 27 22:13:28 <khem> packages-split/udev-utils/sbin/
May 27 22:16:45 <khem> ant__: hmmm oh you are talking about udev-static_124.bb
May 27 22:16:46 <khem> ok
May 27 22:16:51 <khem> now I am with you
May 27 22:17:02 <ant__> :D
May 27 22:18:27 <ant__> probably we should void the FILES_* included from udev.inc
May 27 22:18:40 <khem> FILES_${PN} = "${base_sbindir}/*-${PV}-static"
May 27 22:18:44 <khem> should be doing that
May 27 22:19:03 <khem> but only for udev
May 27 22:19:11 <khem> yeah try to void that
May 27 22:19:18 <ant__> we included: FILES_${PN}-dbg += "${usrbindir}/.debug ${usrsbindir}/.debug"
May 27 22:21:51 <ant__> hm..no
May 27 22:22:02 <khem> FILES_${PN}-dbg = "${base_sbindir}/.debug/*-${PV}-static"
May 27 22:22:28 <khem> add this to udev-static_124.bb
May 27 22:24:26 <ant__> still the do_install is strange...
May 27 22:26:23 <ant__> khem: still not packaged
May 27 22:26:37 <khem> ant__: what is not packaged
May 27 22:26:44 <ant__> mom
May 27 22:27:17 <ant__> http://fr.pastebin.ca/1873150
May 27 22:28:16 <ant__> but then...
May 27 22:28:16 <ant__> NOTE: package udev-static-124-r28.0: task do_package_write_ipk: Started
May 27 22:28:17 <ant__> NOTE: Not creating empty archive for udev-static-151-r13.5
May 27 22:28:23 <ant__> :/
May 27 22:30:08 <ant__> khem: ^^ why 151? must be 124!
May 27 22:31:39 <khem> I dont have 151 appearing here
May 27 22:31:53 <ant__> it's default in my distro
May 27 22:32:28 <khem> but you must be doing bitbake udev-static
May 27 22:32:31 <ant__> I'm tee'ing the log
May 27 22:33:03 <ant__> after -c clean
May 27 22:33:09 <khem> do we need to package
May 27 22:33:16 <khem> these remaining files too I wonder
May 27 22:34:56 <ant__> http://filebin.ca/wyggbf
May 27 22:37:13 <khem> ant__: I can not open that file
May 27 22:37:17 <khem> it says it bin file
May 27 22:37:28 <ant__> hm..text
May 27 22:37:35 <ant__> just d/l it
May 27 22:37:44 <ant__> stupid mime
May 27 22:39:49 <CIA-1> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * rf692b724d9 10openembedded.git/recipes/linux/ (linux-2.6.34/qemuarm/defconfig linux_2.6.34.bb): 
May 27 22:39:49 <CIA-1> linux_2.6.34.bb: Make it to support qemuarm
May 27 22:39:49 <CIA-1> Signed-off-by: Khem Raj <raj.khem@gmail.com>
May 27 22:40:36 <ant__> khem: btw this was the patch (well, the alternative patched init) http://filebin.ca/pwosh
May 27 22:41:29 <khem> ant__: I cant download on this computer 
May 27 22:41:39 <khem> so unless you paste something I can view in browser 
May 27 22:41:49 <ant__> ok, I'll poste it on pastebin, np
May 27 22:41:50 <khem> its useless for me atm
May 27 22:41:59 <ant__> blame .ca !
May 27 22:42:26 <khem> dont use that crap
May 27 22:42:42 <ant__> http://fr.pastebin.ca/1873162
May 27 22:42:52 <ant__> I meant filesbin.ca ;)
May 27 22:43:05 <ant__> filebin, even
May 27 22:47:06 <khem> ant__: patch looks ok
May 27 22:47:18 <dcordes> hi
May 27 22:47:54 <ant__> now we have to deploy DAEMON="/sbin/udevd-124-static"    UDEVADM="/sbin/udevadm-124-static"
May 27 22:48:10 <ant__> but udev-static seems to fail here
May 27 22:48:21 <ant__> I don't have those 2 in my image
May 27 22:49:06 <dcordes> khem, I suspect the problems I face on htcleo are kernel related
May 27 22:49:48 <dcordes> khem, but before I stop I would like to do one more thing and complete the test without neon. as you have seen the build failed
May 27 22:51:54 <khem> ant__: hmm you have install it DISTRO_DEV_MANAGER = "udev-static" may be
May 27 22:52:30 <khem> ant__: or you just have to add it to IMAGE_INSTALL
May 27 22:52:32 <ant__> I'm looking in run.do_install
May 27 22:53:11 <ant__> I've added it as EXTRA_IMAGEDEPENDS += 
May 27 22:53:34 <ant__> but perhaps udev itself could check kernel version
May 27 22:53:47 <ant__> and decide if install this static
May 27 22:54:16 <khem> $ ar p /scratch/oe/deploy/eglibc/ipk/armv5te/udev-static_124-r27.0_armv5te.ipk data.tar.gz | tar -tvz
May 27 22:54:19 <khem> drwxr-xr-x root/root         0 2010-05-27 15:23 ./
May 27 22:54:22 <khem> drwxr-xr-x root/root         0 2010-05-27 15:23 ./sbin/
May 27 22:54:24 <khem> -rwxr-xr-x root/root    538292 2010-05-27 15:23 ./sbin/udevd-124-static
May 27 22:54:27 <khem> -rwxr-xr-x root/root    548316 2010-05-27 15:23 ./sbin/udevadm-124-static
May 27 22:54:57 <ant__> ah, btw it's not machine specific
May 27 22:55:03 <khem> nope
May 27 22:55:09 <khem> not so far
May 27 22:55:16 <ant__> well, udev is
May 27 22:55:47 <khem> ant__: no
May 27 22:55:52 <ant__> here...
May 27 22:56:07 <ant__> probably because of some machine overrides
May 27 22:56:10 <dcordes> ant__, my I ask why you are building that specific version of udev and for which device?
May 27 22:56:15 <khem> ant__: thats possible
May 27 22:56:29 <ant__> udev 151 fails on <2.6.27
May 27 22:56:36 <khem> dcordes: I doubt if its related to kerne
May 27 22:56:53 <khem> dcordes: if kernel can boot other root file systems it could do that for OE too
May 27 22:57:13 <dcordes> well the busybox isn't really demanding..
May 27 22:57:16 <ant__> until we move to 2.6.34 we have to live with this hack (or use other distro)
May 27 22:57:19 <khem> dcordes: one more thing you could try though
May 27 22:57:38 <khem> dcordes: you could use armvt5t userspace and try to boot into that
May 27 22:57:48 <ant__> dcordes: this is for zaurus but is generic issue
May 27 22:57:54 <khem> dcordes: it wont have any confusion about neon or vfp
May 27 22:58:23 <dcordes> khem, I tried to use builds from htcraphael. these machines use the armv6-novfp tunefile
May 27 22:58:27 <dcordes> khem, they fail
May 27 22:58:43 <khem> whats htcraphael ?
May 27 22:58:52 <dcordes> msm7201A based machine
May 27 22:59:01 <khem> ah they fail too 
May 27 22:59:15 <khem> similar to OE ?
May 27 22:59:48 <khem> ant__: why does udev 151 fails on <2.6.27
May 27 22:59:55 <ant__> lacking headers
May 27 23:00:03 <khem> is it ppoll issue
May 27 23:00:18 <ant__> khem: pls try to prefer udev_151 in your build
May 27 23:00:26 <khem> ant__: I have it
May 27 23:00:29 <ant__> the issue is not apparent if you use 124 possibly
May 27 23:00:32 <khem> and it works well on qemu
May 27 23:00:37 <ant__> I don't have the static...
May 27 23:00:42 <ant__> s@t
May 27 23:00:49 <JaMa> khem: here is boot output http://pastebin.ca/1873165 image was whole built with this patch applied http://gitorious.org/~jama/angstrom/jama-shr-experimental/commit/788e17eb98cf76c5edbe2f3e0129027d8f8e8329 (Added it also to BUILD_OPTIMIZATION hoping it won't harm..)
May 27 23:00:51 <khem> I am using 151 and 2.6.34 on qemu arm
May 27 23:01:38 <JaMa> but now I've to go sleep..
May 27 23:03:16 <ant__> khem: see here :/  http://fr.pastebin.ca/1873166
May 27 23:03:17 <khem> JaMa: before you sleep
May 27 23:03:26 <khem> JaMa: did you compile kernel with this option 
May 27 23:03:28 <ant__> btw you build minimal/eglibc, isnt?
May 27 23:03:29 <khem> prolly not
May 27 23:03:43 <khem> JaMa: here is deal
May 27 23:03:50 <khem> compile the kernel manually
May 27 23:04:12 <khem> unless you can make sure that the option was used to compile the kernel too
May 27 23:04:37 <khem> ant__: yes
May 27 23:04:59 <ant__> here is Angstrom/glibc fwiw
May 27 23:05:24 <ant__> somehow 151 steals the task :/
May 27 23:06:25 <khem> r13.5
May 27 23:06:27 <JaMa> khem: ah I see what you mean.. sorry I was already sleepy before..
May 27 23:07:02 <khem> I modifies the toplevel Makefile
May 27 23:07:04 <JaMa> khem: you were talking about this flag added to kernel makefile (not about init= :))
May 27 23:07:14 <khem> JaMa: yes
May 27 23:07:49 <JaMa> sorry I misunderstood before.. rebuilding now
May 27 23:07:56 <khem> ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
May 27 23:07:56 <khem> KBUILD_CFLAGS   += -Os
May 27 23:07:56 <khem> else
May 27 23:07:56 <khem> KBUILD_CFLAGS   += -O2 #-fno-ipa-sra 
May 27 23:07:56 <khem> endif
May 27 23:08:08 <khem> and i think you build with CONFIG_CC_OPTIMIZE_FOR_SIZE
May 27 23:08:23 <khem> so add -fno-ipa-sra to first KBUILD_CFLAGS
May 27 23:08:39 <khem> ie KBUILD_CFLAGS   += -Os -fno-ipa-sra
May 27 23:08:49 <khem> or to both it does not matter
May 27 23:09:45 <khem> even if its passed in thru CC , KBUILD_CFLAGS will be appended to commandline 
May 27 23:09:57 <JaMa> building..
May 27 23:09:58 <khem> which means the effect will be nullified once you specify -Os or -O2 again
May 27 23:10:09 <khem> last -O rules
May 27 23:10:24 <khem> if you have -O2 -O3 -O1 -O0
May 27 23:10:28 <khem> then gcc takes in O0
May 27 23:10:55 <khem> and O2 implied -fipa-sra
May 27 23:11:08 <khem> or even -Os does same
May 27 23:12:15 <JaMa> hmm night backup already started, build is getting slower..
May 27 23:12:29 <khem> in nutshell -fno-ipa-sra should appear in the very end of compiler commandline
May 27 23:12:40 <khem> JaMa: ok it take few mins
May 27 23:12:58 <khem> JaMa: are you GMT +2
May 27 23:13:43 <khem> must be late there
May 27 23:14:04 <JaMa> 1:12 AM..
May 27 23:14:32 <JaMa> but I promised boss to arrive in time tomorrow for presentation... so I'll wake up around 6am :/
May 27 23:15:36 <ant__> khem: I found udev bot in workdir/armv5te and workdir/c7x0  what a mess...
May 27 23:15:44 <ant__> s/bot/both/
May 27 23:16:32 <dcordes> khem, sorry. major 3g outage
May 27 23:17:50 <dcordes> khem, are you still there?
May 27 23:19:22 <JaMa> khem: boot looks the same, I'll recheck if that flag was applied right (tomorrow)
May 27 23:20:03 <khem> JaMa: ok
May 27 23:20:09 <khem> good night
May 27 23:20:19 <ant__> bye JaMa 
May 27 23:20:28 <JaMa> gnight
May 27 23:26:35 <JaMa> khem: http://paste.pocoo.org/show/219129/ is part of log.do_compile with make V=1 showing it was applied..
May 27 23:28:36 <dcordes> khem, you think it's worth the try completing the 'cortex-a8 no-neon' build ?
May 27 23:28:42 <dcordes> khem, I did not understand why it failed
May 27 23:30:12 <khem> dcordes: prolly yes 
May 27 23:30:18 <khem> tell me waht was error
May 27 23:31:24 <dcordes> khem, I will dig it out. 1minute
May 27 23:32:34 <dcordes> http://tinderbox.openembedded.org/public/logs/task/5923332.txt
May 27 23:33:22 <khem> ah ok
May 27 23:33:28 <khem> get rid of this -mfloat-abi=softfp
May 27 23:34:35 <khem> machine/include/tune-cortexa8.inc
May 27 23:34:54 <khem> machine/include/tune-armv7.inc actually
May 27 23:34:59 <khem> TARGET_CC_ARCH
May 27 23:35:19 <khem> make it TARGET_CC_ARCH = "-march=armv7"
May 27 23:36:10 <khem> and in machine/include/tune-cortexa8.inc
May 27 23:36:24 <khem> make TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8"
May 27 23:36:54 <khem> this should fix it hopefully
May 27 23:37:17 <dcordes> right now I have this
May 27 23:37:20 <dcordes> -TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon ${ARM_FP_OPT}"
May 27 23:37:20 <dcordes> +TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 ${ARM_FP_OPT}"
May 27 23:37:46 <khem> ARM_FP_OPT is no good
May 27 23:38:48 <dcordes> should I keep that?
May 27 23:38:59 <ant__> khem: after one beer I see my issue
May 27 23:39:09 <ant__> udev-static is bad split
May 27 23:39:37 <dcordes> khem, hold on.. I think this is leading nowhere. I bet I will end up getting something confused. can you perhaps post a patch?
May 27 23:40:04 <khem> dcordes: hmm follow the steps I said above
May 27 23:40:23 <khem> you need to modify two files machine/include/tune-cortexa8.inc and machine/include/tune-armv7.inc
May 27 23:40:33 <khem> and what you need to change is there
May 27 23:40:37 <ant__> khem: my workdir seems insane.
May 27 23:40:44 <khem> ant__: heh
May 27 23:40:48 <ant__> I'll rebuild from scratch and let you know
May 27 23:40:57 <khem> ant__: sure
May 27 23:41:08 <dcordes> ok right you put the full lines sorry
May 27 23:41:11 <ant__> I have a bogus udev-151-r13 in /armv5te
May 27 23:41:13 <khem> but I think we generate -static automatically
May 27 23:41:26 <khem> so udev-static may be a bad choice
May 27 23:41:31 <khem> for the recipe
May 27 23:42:20 <khem> although it fits the purpose
May 27 23:42:46 <ant__> I have even  udev-151-r11 in /armv5te :/
May 27 23:42:56 <khem> /scratch/oe/work/armv5te-oe-linux-gnueabi/udev-151-r11/packages-split
May 27 23:43:03 <khem> I have udev-static :)
May 27 23:43:20 <khem> along with others like udev-dev aand udev-doc etcx. etc.
May 27 23:44:03 <dcordes> khem, http://privatepaste.com/b29f722536 <- this is the diff with all the relevant changes. can you take a look?
May 27 23:44:22 <khem> ant rename the recipe to something like udev-nodynamic
May 27 23:44:52 <dcordes> khem, gonna build minimal-image with this in f692b724d9cb01cfa6f3bc6a5f171084b1cc503c
May 27 23:44:55 <khem> dcordes: perfect
May 27 23:46:29 <khem> ant__: http://pastebin.com/tkj3tRbu potential problems :)
May 27 23:46:32 <khem> have another beer 
May 27 23:48:10 <ant__> now is renamed udev-hack_124.bb ;)
May 27 23:49:13 <ant__> khem: about those xy-static recipes....I'm guilty ;)
May 27 23:49:48 <ant__> probably one should create the generic recipe and hack around the dev, dbg, static
May 27 23:50:02 <ant__> but here it was clearly a klibc static binary
May 27 23:50:43 <dcordes> ant__, why are you building udev static? is that also something kernel related?
May 27 23:51:09 <ant__> hm...really we just want the old udevadm and udevd
May 27 23:51:28 <ant__> same toolchain
May 27 23:56:43 <khem> ant__: I would say patch kernel to work with new udev
May 27 23:57:28 <khem> recipes/linux-libc-headers/linux-libc-headers-2.6.31/0001-implement-TIF_RESTORE_SIGMASK-support-and-enable-the.patch
May 27 23:57:32 <khem> is the patch you need
May 27 23:57:57 <ant__> khem: hm, interesting
May 27 23:58:11 <mwester-laptop> Are the madwifi drivers finally in any recent Linux kernels yet?
May 27 23:58:12 <ant__> was just temporarly until all devices move to 2.6.3x
May 27 23:58:42 <mwester-laptop> (the out-of-kernel madwifi-ng modules won't build with gcc 4.4.2, and gcc 4.2.4 won't build anymore since we did the sysroot thing :(  )
May 27 23:58:45 <khem> ant__: this patch is not merged in upstream yet I think
May 27 23:58:53 <khem> so even 2.6.34 will need it 
May 27 23:59:20 <khem> mwester-laptop: whats the error
May 27 23:59:38 <khem> We can fix the module
May 28 00:00:18 <mwester-laptop> I didn't even look at the error in madwifi -- I'd bet lunch that it's the closed-source hal.o binaries.
May 28 00:00:53 <mwester-laptop> Boost also failed with 4.4.2, but I don't use that so that's somebody else's problem, I think.  :D
May 28 00:02:24 <mwester-laptop> I was hoping that the madwifi drivers made it into the kernel finally, which would resolve this issue for me.  I can't fix the toolchain problem, and I'd rather not waste more time on those silly madwifi-ng drivers if I can spend it on something more productive, like moving the NSLU2 to a newer kernel instead. :)
May 28 00:02:28 <dcordes> khem, I really hope this will build and lead to some useful new conclusion. need to get somewhere with this.. thanks again for the efforts
May 28 00:03:01 <dcordes> hitting the sheets
May 28 00:03:03 <dcordes> good night
May 28 00:04:26 <khem> ant__: oh the patch I mentioned has made upstream I am seeing it in 2.6.34 so you will be good
May 28 00:04:46 <ant__> good, we have 2.6.34 on some machines
May 28 00:05:10 <khem> ant__: and make sure you use 2.6.31 for linux-libc-headers
May 28 00:06:44 <ant__> now I'm battling with the renamed recipe...sob the inc sets too much
May 28 00:07:05 <ant__> cp: cannot stat `/oe/openembedded/recipes/udev/files/c7x0/flags.patch': No such file or directory
May 28 00:07:19 <ant__> seems  have to edit FILESPATHPKG or alike
May 28 00:08:14 <mwester-laptop> initscripts has an example that sounds sorta like what you need to fix that.
May 28 00:09:20 <khem> mwester-laptop: no idea about madwifi-ng
May 28 00:09:28 <khem> my guess is its not merged yet
May 28 00:11:16 <ant__> my bad..did not rename the dir :P
May 28 00:13:31 <ant__> bingo
May 28 00:13:41 <ant__> khem: once renamed all is fine
May 28 00:14:03 <ant__> packaging task was mixed up..
May 28 00:14:47 <ant__> now, renaming it to udev-compat-static?
May 28 00:21:55 <ant__> ok, good night
May 28 00:53:43 <IgorK> khem: do u have wright rights to that git repository? I fixed the patch file and wants to make sure it is updated....
**** ENDING LOGGING AT Fri May 28 03:00:14 2010