**** BEGIN LOGGING AT Sun Sep 19 02:59:56 2010
Sep 19 07:30:40 <ynezz> What's the reason for disabled interactive mode in bitbake?
Sep 19 07:31:58 <ynezz> Is there any workaround? Something, that I don't need to wait each time to get parsed thousand of recipes
Sep 19 09:24:36 <atiti> hi
Sep 19 13:43:13 <eFfeM> good sunday!
Sep 19 13:50:38 <Crofton> gm
Sep 19 13:51:22 <eFfeM> Crofton got your perl problem resolved ?
Sep 19 13:51:39 <Crofton> yes, thanks
Sep 19 13:52:05 <eFfeM> yw
Sep 19 13:53:40 <eFfeM> Crofton one other Q: if I recall correctly I saw in the log that you didn't want a dead file to be removed as you were working on it. That is fine with me, but I have no idea which recipe or file you were referring to
Sep 19 13:54:09 <Crofton> there is a patch in boost
Sep 19 13:54:33 * eFfeM wants to clean up,but not give people a hard time or throw away things that are useful, but sometimes this is a difficult judgement
Sep 19 13:54:44 <Crofton> that patches in some arm asm to replace the atomix intrinsics
Sep 19 13:54:51 <eFfeM> ok
Sep 19 13:55:08 <Crofton> now, implementations were backported into gcc for them
Sep 19 13:55:15 <Crofton> so the patch is nt necessary
Sep 19 13:55:35 <Crofton> but, the implementation in the patch is *much* better than what is in gcc atm
Sep 19 13:55:45 <Crofton> so I am very likely going to use that patch again
Sep 19 13:55:49 <Crofton> when I get a chance
Sep 19 13:56:00 <Crofton> I rather not have to fish through logs looking for it
Sep 19 13:56:39 <eFfeM> ok, I'll skip boost, np, btw there are 8 unused patch files for boost
Sep 19 13:56:45 <eFfeM> i understand
Sep 19 13:56:55 <Crofton> I am sure
Sep 19 13:57:00 <Crofton> boost is a pain
Sep 19 13:57:09 <Crofton> if you touch boost
Sep 19 13:57:16 <eFfeM> (btw the files are not deleted, they are moved to obsolete, so they are still findable)
Sep 19 13:57:17 <Crofton> upgrade to the latest version
Sep 19 13:57:32 <Crofton> also boost has api changes which makes it a nuisance
Sep 19 13:57:40 <eFfeM> i know we had an issue with boost at work
Sep 19 13:57:47 <Crofton> well, in this case, leave it all in one place
Sep 19 13:57:52 <eFfeM> and it seems to become bigger with every release
Sep 19 13:58:00 <Crofton> the other headache is the currrent version uses cmake
Sep 19 13:58:06 <eFfeM> yup, i'll keep it
Sep 19 13:58:11 <eFfeM> cmake :-(
Sep 19 13:58:12 <Crofton> which is not being maintained in boost
Sep 19 13:58:21 <Crofton> cmake is better than bjam
Sep 19 13:58:32 <Crofton> so to update the recipe, we have to unbreak bjam
Sep 19 14:00:35 <Crofton> yes, boost is a pain in the hindquarters
Sep 19 14:46:16 <Unhelpful> I'm having a bit of an issue w/ OE... I'd like to build a set of installable packages to add to android phones, and in some cases root is going to be an initramfs or otherwise not writable or persistent.
Sep 19 14:48:48 <Unhelpful> so i've been trying to prefix *all* paths with a new install_prefix variable, by defining prefix and base_prefix as ${install_prefix}/usr and ${install_prefix}. but it all falls apart when the prefix is used in the cross-compiler sysroot, and the cross-compiler can't generate binaries because it can't find crt.o, libc.so, etc.
Sep 19 14:50:25 <Unhelpful> any idea how to fix this, or can ipk be set up so that it can install under a prefix and also fix up binaries to have appropriate rpath and dynamic linker entries for the prefix?
Sep 19 15:12:31 <eFfeM> hm, no idea on that
Sep 19 15:13:17 <eFfeM> warning: cleanup patches for recipes starting with f and i coming (total about 10 recipe dirs cleaned)
Sep 19 15:13:47 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r4dd3873a2a 10openembedded.git/recipes/initscripts/initscripts-1.0/slugos/ (devices.patch rootopts.patch): 
Sep 19 15:13:47 <CIA-68> initscripts : moved unused files to obsolete dir
Sep 19 15:13:47 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:13:48 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r4017be01ac 10openembedded.git/recipes/icedtea/icedtea6-native-1.7.3/icedtea-ecj-disable-sanitychecks.patch: 
Sep 19 15:13:48 <CIA-68> icedtea : moved unused files to obsolete dir
Sep 19 15:13:48 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:13:53 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r55c971f5eb 10openembedded.git/recipes/iputils/files/ (7 files): 
Sep 19 15:13:53 <CIA-68> iputils : moved unused files to obsolete dir
Sep 19 15:13:53 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:14:09 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r78d655946f 10openembedded.git/recipes/ffalarms/atd-over-fso/ (init.d-atd-restart.patch no-oknodo.patch): 
Sep 19 15:14:09 <CIA-68> ffalarms : moved unused files to obsolete dir
Sep 19 15:14:09 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:14:09 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r707d89e0be 10openembedded.git/recipes/fontconfig/files/one-j-too-many.patch: 
Sep 19 15:14:15 <CIA-68> fontconfig : moved unused files to obsolete dir
Sep 19 15:14:15 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:14:15 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r437ba8f133 10openembedded.git/recipes/flite/flite-alsa-1.2/flite-alsa-1.2-configure-with-audio.patch: 
Sep 19 15:14:15 <CIA-68> flite : moved unused files to obsolete dir
Sep 19 15:14:15 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:14:15 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r9663ae8a4e 10openembedded.git/recipes/ffmpeg/omapfbplay/fbplay-static.diff: 
Sep 19 15:14:16 <CIA-68> ffmpeg : moved unused files to obsolete dir
Sep 19 15:14:16 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:14:17 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * re35c6d6688 10openembedded.git/recipes/frodo/frodo-4.2/no-pref-editor.patch: 
Sep 19 15:14:17 <CIA-68> frodo : moved unused files to obsolete dir
Sep 19 15:15:11 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:15:11 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r8a77421fb3 10openembedded.git/recipes/fbreader/files/ (change-desktop.patch hack-makefile.patch set-target.patch): 
Sep 19 15:15:11 <CIA-68> fbreader : moved unused files to obsolete dir
Sep 19 15:15:11 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:15:12 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r1a617b7e99 10openembedded.git/recipes/iscsi-target/iscsi-target/ (2.6.31.patch 2.6.32.patch): 
Sep 19 15:15:12 <CIA-68> iscsi-target : moved unused files to obsolete dir
Sep 19 15:15:13 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:15:13 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r190933d1cd 10openembedded.git/recipes/freesmartphone/fsogsmd/0001-fsogsmd-update-sysfs-node-in-config-for-openmoko_gta.patch: 
Sep 19 15:15:14 <CIA-68> freesmartphone : moved unused files to obsolete dir
Sep 19 15:15:15 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:15:15 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r83dff79fa2 10openembedded.git/recipes/yaffs2/ (yaffs2-utils.inc yaffs2-utils_cvs.bb): 
Sep 19 15:15:16 <CIA-68> (13 lines omitted)
Sep 19 15:15:26 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r7e2256ab70 10openembedded.git/recipes/ipkg/files/ (libdir.patch uclibc.patch uninclude-replace.patch): 
Sep 19 15:15:26 <CIA-68> ipkg : moved unused files to obsolete dir
Sep 19 15:15:26 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:15:26 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r57f87fad39 10openembedded.git/recipes/freenx/nxkill/Makefile.in.patch: 
Sep 19 15:15:27 <CIA-68> freenx : moved unused files to obsolete dir
Sep 19 15:15:27 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:15:45 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r62b5358d16 10openembedded.git/recipes/initscripts/initscripts-slugos_1.0.bb: 
Sep 19 15:15:45 <CIA-68> initscripts-slugos_1.0.bb: improved FILESPATHPKG
Sep 19 15:15:46 <CIA-68> At least one file did not unpack properly, the slugos dir has several
Sep 19 15:15:46 <CIA-68> files in it, so modified FILESPATHPKG to first look at that dir
Sep 19 15:15:47 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:16:07 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r7a865f5cc2 10openembedded.git/recipes/ifupdown/ifupdown-0.6.10/head-tail.patch: 
Sep 19 15:16:07 <CIA-68> ifupdown : moved unused files to obsolete dir
Sep 19 15:16:07 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:21:37 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r2fd88f3594 10openembedded.git/recipes/python/python-tlslite_0.3.8.bb: 
Sep 19 15:21:37 <CIA-68> python-tlslite_0.3.8.bb: bump PR
Sep 19 15:21:37 <CIA-68> didn't bump PR yesterday when fixing SRC_URI but on hindsight
Sep 19 15:21:37 <CIA-68> it can be convenient in some cases (especially if you have a
Sep 19 15:21:37 <CIA-68> failed build around) so here's the bump.
Sep 19 15:21:38 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 15:39:21 <Unhelpful> eFfeM: maybe try the ML? and aside from convenience adding the prefix at install doesn't take care of conf/data correctly.
Sep 19 15:42:23 <Crofton> yeah
Sep 19 15:42:40 <Crofton> I'm not familiar with using OE for Android
Sep 19 15:42:44 <Crofton> curious though
Sep 19 15:50:34 <Unhelpful> Crofton: android has a linux kernel but the userspace is almost entirely unique, and only a few unix utilities that are expected to be needed are included.
Sep 19 15:50:49 <Unhelpful> most things won't even build against the android libc w/o serious modification
Sep 19 15:52:27 <Unhelpful> it's pretty common for custom ROMs to include a few more things, and a busybox that is either modified to build against android libc or static linked to uclibc, but i thought maybe a packageset would be better. :)
Sep 19 15:53:00 <Crofton> it seems like we would need to add support for Android toolchain into OE
Sep 19 15:54:31 <Unhelpful> hah, no, you'd need to modify *everything* to support the libc.
Sep 19 15:55:51 <Unhelpful> i was just looking to build a toolchain and use that for the binaries, but prefixing all installed files is turning out to be tricky
Sep 19 16:13:04 <eFfeM> Unhelpful: ML = mailing list
Sep 19 16:13:15 <Unhelpful> eFfeM: yes :)
Sep 19 16:14:03 <eFfeM> seems a good idea
Sep 19 16:14:09 <eFfeM> to try ML
Sep 19 16:14:48 <eFfeM> and we have two android related recipes
Sep 19 16:14:49 <eFfeM> android-image-utils-native_git.bb  android-rpc_git.bb
Sep 19 16:14:55 <eFfeM> ni idea what they do though
Sep 19 16:15:07 <Unhelpful> oh, i didn't find those, but i'll look :)
Sep 19 16:15:13 <kergoth_> Unhelpful: heh, might want to replace all the recipes entirely, just use oe's classes as a starting point
Sep 19 16:15:15 <Unhelpful> i imagine it's not what i want though.
Sep 19 16:17:50 <mr_nice> isn't it possible to use bionic and glibc side by side with different environments?
Sep 19 16:18:16 <Tartarus> possible or easy?
Sep 19 16:18:24 <mr_nice> possible :)
Sep 19 16:18:34 <Tartarus> Everything is possible, yes :)
Sep 19 16:18:41 <Tartarus> No, it's not very easy, but it's doable
Sep 19 16:19:52 <Tartarus> Mixing the two depends on what you're after
Sep 19 16:19:56 <Tartarus> clean product or hacking around
Sep 19 16:21:36 <Unhelpful> mr_nice: well, that's basically what i'm looking for, actually, uclibc or eglibc and a set of utilities linked to it that use rpath and don't rely on android system components at all.
Sep 19 16:21:49 <mr_nice> I need to start reading a bit more about bionic it would be interesting which things it implements glibc is not capable of
Sep 19 16:22:12 <Tartarus> mr_nice: it's the other way around, for the most part
Sep 19 16:22:17 <CIA-68> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r89741bcf9b 10openembedded.git/recipes/angstrom/angstrom-x11-base-depends.bb: angstrom-x11-base-depends: switch default to xorg
Sep 19 16:22:27 <Tartarus> the big deals(tm) about bionic are license and some custom android calls/etc
Sep 19 16:22:55 <Tartarus> Unhelpful, it wouldn't be too hard, I think, to just take say the micro distribution in OE and change the prefix it installs everything into into something else
Sep 19 16:23:10 <mr_nice> Tartarus: ah ok thx
Sep 19 16:23:20 <Tartarus> ie /oe/ and have that be where your other utils live on the android env
Sep 19 16:23:46 <Unhelpful> Tartarus: that was my starting point. the trouble is that the cross-compiler sysroot is using that prefix too.
Sep 19 16:23:55 <Unhelpful> but doesn't know to search under in :(
Sep 19 16:24:08 <Unhelpful> s/in/it/
Sep 19 16:24:12 <Tartarus> Unhelpful, it should if you changed it right
Sep 19 16:24:32 <Tartarus> But maybe you need to play with TOOLCHAIN_OPTIONS=--sysroot=..
Sep 19 16:24:37 <Unhelpful> and i don't know how to change it *right* :/
Sep 19 16:25:14 <Unhelpful> obviously simply adding install_prefix to prefix and base_prefix isn't sufficient.
Sep 19 16:26:55 <Unhelpful> so something like TOOLCHAIN_OPTIONS="--sysroot=${install_prefix}"?
Sep 19 16:28:30 <Tartarus> check w/ bitbake -e that it points to the right spot
Sep 19 16:28:56 * Unhelpful did not know about bitbake -e ;)
Sep 19 16:29:38 <Unhelpful> also there's gcc-configure-cross.inc that already deals w/ sysroot.
Sep 19 16:32:46 <sorvats> which is the safest way of reconfiguring the kernel without going into menuconfig? I'm having serious terminal issues to see menuconfig if I run it by hand, and it asks for gnome-terminal when ran from bitbake
Sep 19 16:34:00 <ynezz> just configure it in your work dir
Sep 19 16:38:00 <sorvats> so just throwing my custom defconfig in there should just work?
Sep 19 16:38:56 <sorvats> for I know oe will try to apply xm_x2xx_defconfig from my boards dir under the linux recipe dir in oe
Sep 19 16:39:17 <Tartarus> sorvats, you can change it to use 'screen'
Sep 19 16:39:26 <Tartarus> see conf/bitbake.conf and search for TERMCMD
Sep 19 16:40:33 <sorvats> oh, that's nice stuff
Sep 19 16:40:37 <sorvats> ty
Sep 19 17:10:43 <CIA-68> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r15e96b8ac8 10openembedded.git/recipes/angstrom/angstrom-x11-base-depends.bb: angstrom-x11-base-depends: fix typo
Sep 19 17:10:53 <Crofton|work> heh
Sep 19 18:25:32 <Unhelpful> Tartarus: so i can do something like bitbake -e <recipe> to see what the actual environment is when that builds?
Sep 19 18:25:59 <khem> gm all
Sep 19 18:26:53 <florian> hi all
Sep 19 18:27:00 <khem> Unhelpful: yes something like bitbake -e -b <recipe> | grep "<var>="
Sep 19 18:27:04 <khem> florian: hey
Sep 19 18:27:27 <khem> florian: do you know who takes care of openmoko  recipe now a days
Sep 19 18:27:46 <Unhelpful> khem: excellent, it's nice to know how to fix something myself ;D
Sep 19 18:28:01 <khem> Unhelpful: helpful ?
Sep 19 18:29:04 <Unhelpful> khem: i hope so, i'm trying to add a prefix to *all* paths in the target filesystem, but it's going wrong at in gcc-cross-intermediate, or possibly before, when gcc can't find sysroot files.
Sep 19 18:29:43 <khem> Unhelpful: interesting 
Sep 19 18:30:02 <florian> khem: not really, but mickey|away might know
Sep 19 18:30:18 <Unhelpful> khem: it's for providing useful packages that are entirely independent of an existing system (android, but maybe useful elsewhere)
Sep 19 18:30:30 <Unhelpful> non of android is really linux *enough* to use besides the kernel ;)
Sep 19 18:30:45 <khem> Unhelpful: prefix = ""
Sep 19 18:30:45 <khem> exec_prefix = ""
Sep 19 18:30:45 <khem> prefix_native = ""
Sep 19 18:30:46 <khem> exec_prefix_native = ""
Sep 19 18:30:55 <khem> will reset it
Sep 19 18:31:05 <khem> iow you can define it to whatever you want
Sep 19 18:31:14 <Unhelpful> khem: yes, i found those, but i actually wan something like prefex(etc) = "/data/overlay"
Sep 19 18:31:41 <khem> Unhelpful: that would be confdir
Sep 19 18:31:41 <Unhelpful> the problem is that the crosscompiler doesn't find the sysroot files any more because the sysroot has that layout too, and it doesn't seem to know.
Sep 19 18:31:51 <Unhelpful> confdir?
Sep 19 18:32:00 <khem> but it may not work still because these variables are not used everywhere 
Sep 19 18:32:06 <khem> in all recipes
Sep 19 18:32:17 <khem> intention to use them is there though
Sep 19 18:32:49 <khem> Do you just want to move the complete root file system structure to somewhere or only few known dirs like bin sbin 
Sep 19 18:33:03 <Unhelpful> absolutely everything.
Sep 19 18:33:08 <khem> it will be hard to control each separately
Sep 19 18:33:34 <khem> though there are knobs but they are loosely coupled and its assuming that the rfs is linux/unix like
Sep 19 18:33:35 <Unhelpful> i started w/ the micro distro since it already manipulates prefix to flatten away /usr
Sep 19 18:33:45 <khem> right thats good
Sep 19 18:34:19 <Unhelpful> the trouble seems to be that *that* still works because it's not moving /lib
Sep 19 18:35:06 <khem> yes 
Sep 19 18:35:33 <khem> yes /lib is also encoded into binaries for ldso use
Sep 19 18:35:53 <khem> so it will take some more to move /lib elesewhere
Sep 19 18:36:06 <khem> ideally OE should have taken care 
Sep 19 18:36:30 * Unhelpful already has added LDFLAGS for changing the path to the dynamic linker and rpaths.
Sep 19 18:40:50 <khem> ok
Sep 19 18:41:08 <khem> then you must be all set to go
Sep 19 18:41:49 <Unhelpful> well, i *think* i've done the right thing to gcc-configure-cross.inc now :)
Sep 19 18:42:11 <Unhelpful> seems the easiest place to tackle this would be just to tell GCC about the different sysroot layout.
Sep 19 18:43:49 <khem> Unhelpful: hmmm sysroot will not fix dynamic linker path
Sep 19 18:44:41 <khem> the syminks/ld script stubs in /usr/lib need fixing too so they point to correct new /lib
Sep 19 18:44:49 <khem> whereever you put it
Sep 19 18:44:59 <khem> in short it will need some hacking 
Sep 19 18:45:52 <eFfeM> mickey|away: once you get ! away: would appreciate your feedback on the python patch I posted (python-modules used to depend on python-dev)
Sep 19 18:47:49 <Crofton|work> eFfeM, mickey|away is on vacation
Sep 19 18:48:40 <eFfeM> Crofton|work: ouch
Sep 19 18:48:56 <eFfeM> do we have another python wiz ?
Sep 19 18:49:29 <eFfeM> Crofton you know until when?
Sep 19 18:50:29 <Unhelpful> khem: i'm fixing the dynamic linker path already via LDFLAGS but that's probably not the prettiest place. :)
Sep 19 18:50:52 <eFfeM> btw has there been any tsc activity last few months? Last minutes are from june
Sep 19 18:52:43 <Crofton> eFfeM, sounds like you are one
Sep 19 18:52:56 <Crofton> they were talking about meeting minutes recently
Sep 19 18:58:04 <eFfeM> ouch, i know a little bit about the perl stuff but didn't do too much on python
Sep 19 19:03:03 <CIA-68> 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r32bb2e3385 10openembedded.git/recipes/tasks/task-nas-server.bb: 
Sep 19 19:03:03 <CIA-68> task-nas-server: added tgt
Sep 19 19:03:03 <CIA-68> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Sep 19 19:33:41 <GNUtoo|laptop> eFfeM, hi
Sep 19 19:33:54 <GNUtoo|laptop> what's the recipe removal procedure?
Sep 19 19:36:22 <khem> eFfeM: you moved so many patches to obsolete 
Sep 19 19:37:00 <khem> which as a whole is a good thing but I would have suggested to get them to ml before committed
Sep 19 19:37:19 <khem> eFfeM: did you build the recipes or what sort of testing did you do
Sep 19 19:40:31 <CIA-68> 03Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> 07org.openembedded.dev * r058f70b656 10openembedded.git/recipes/wesnoth/ (wesnoth-wvga_1.8.4.bb wesnoth.inc wesnoth_1.8.4.bb): (log message trimmed)
Sep 19 19:40:31 <CIA-68> wesnoth: add inc factorized 1.8.4 version, with normal and wvga versions
Sep 19 19:40:31 <CIA-68> Wesnoth is a strategy game and features more than one type of GUI,
Sep 19 19:40:31 <CIA-68> each GUI type(normal,smallGUI,tinyGUI) has some minimum resolution constraint.
Sep 19 19:40:31 <CIA-68> If the minimum resolution is not met, the game abort due to some asertions
Sep 19 19:40:31 <CIA-68> in the code.
Sep 19 19:40:32 <CIA-68> Unlike the choice between normal and smallGUI that can be made at runtime,
Sep 19 19:40:41 <CIA-68> 03Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> 07org.openembedded.dev * r0238bf7cf5 10openembedded.git/recipes/supertux/supertux_0.1.3.bb: (log message trimmed)
Sep 19 19:40:41 <CIA-68> supertux 0.1.3: depend on libmikmod(fix not-starting issue)
Sep 19 19:40:41 <CIA-68> If we don't depend on libmikmod, and that we enable sound and/or music
Sep 19 19:40:41 <CIA-68> supertux exits with an error message and doesn't start:
Sep 19 19:40:42 <CIA-68> root@nokia900 ~ # supertux
Sep 19 19:40:43 <CIA-68> Datadir: /usr/bin/../share/supertux
Sep 19 19:40:43 <CIA-68> Warning: No joysticks are available.
Sep 19 19:43:49 <eFfeM> khem, this was discussed to great lengths on the list
Sep 19 19:46:47 <eFfeM> see this thread: http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/024195.html
Sep 19 19:47:23 <eFfeM> it includes also what testing I did 
Sep 19 19:48:23 <eFfeM> but if you prefer some 160 postings to the ML that can also be done, but I strongly doubt that that is going to be effective (as also stated in the thread above)
Sep 19 19:50:44 <khem> eFfeM: you have seen people are not comfortable with large changes
Sep 19 19:51:13 <khem> eFfeM: what works for one does not work for all. Personally I am happy with changes if they are tested well
Sep 19 19:51:25 <khem> eFfeM: you could create user branch for such changes
Sep 19 19:51:36 <khem> and post the link to the git brach
Sep 19 19:51:49 <khem> you dont need to send any patches to ml
Sep 19 19:52:16 <eFfeM> GNUtoo|laptop: wrt removal: depends on what you want to remove, if it is an old version of a recipe that you maintain, i think you can remove it safely remove yourself (assuming the recipe is not pinned or so), otherwise I suggest posting a patch to the list
Sep 19 19:53:02 <eFfeM> khem, the procedure was discussed on the list and i got no objections on it
Sep 19 19:53:08 <GNUtoo|laptop> ok
Sep 19 19:53:15 <GNUtoo|laptop> it's for old versions of wesnoth
Sep 19 19:53:22 <GNUtoo|laptop> I'll send a patch then
Sep 19 19:53:29 <GNUtoo|laptop> to see if that annoy people
Sep 19 19:53:40 <eFfeM> khem, and yes, they are well tested: I have run bitbake -c patch for all recipes that may depend on the files moved
Sep 19 19:54:30 <eFfeM> that is why I came upon things like the yaffs2-utils and python-tlslite recipes not working
Sep 19 19:55:14 <khem> eFfeM: thats nice. 
Sep 19 19:55:38 <khem> I guess we should start using some nice feature of git and cheap branching
Sep 19 19:56:58 <khem> eFfeM: dont you agree that getting help on getting stuff tested by others dev is more effective ?
Sep 19 19:57:19 <eFfeM> well i doubt if it was done in a branch, people would look at it it just creates extra work (as the branch might deviate etc)
Sep 19 19:57:47 <eFfeM> khem, I tried the branch thing back in april, got zero, nada, niente, no feedback at all :-(
Sep 19 19:57:51 <khem> eFfeM: I dont think so, atleast I for one would simply track your branch 
Sep 19 19:57:53 <eFfeM> or march
Sep 19 19:58:30 <eFfeM> it would greatly help if maintainers would clean up their own dirs....
Sep 19 19:58:46 <eFfeM> and it would also greatly help if the maintainer of a recipe was known
Sep 19 19:59:58 <khem> eFfeM: look at how buildroot operated they have less developers than OE but they manage the project better than us I feel
Sep 19 20:00:22 <eFfeM> I *have* split it in small increments to avoid disconforting people too much (as was requested)
Sep 19 20:00:46 <eFfeM> sry, no idea how buildroot organizes things. 
Sep 19 20:01:42 <eFfeM> *the* problem with OE is that everyone can toss in a recipe, and never look after it, causing it to rot; there is insufficient ownership
Sep 19 20:02:02 <khem> eFfeM: yes thats true
Sep 19 20:02:12 <Unhelpful> heh: echo /media/external_ext/openembedded/tmp/sysroots/armv7a-oe-linux-uclibceabi/data/overlay${sysroot_headers_suffix}/data/overlay/include
Sep 19 20:02:27 <khem> eFfeM: as I have noted in some of my posts that OE should not become a dump yard
Sep 19 20:03:04 <Jay7> in freebsd ports that unmet some current requirements marked as to be removed
Sep 19 20:03:21 <Jay7> this happens in port freeze period before release
Sep 19 20:03:27 <Unhelpful> looks like fixinc somehow doubles my install_prefix. probably one is from the sysroot having install_prefix appended and one is from includedir being prefixed with it, i'd guess?
Sep 19 20:03:33 <Jay7> JFYI :)
Sep 19 20:04:26 <eFfeM> khem, I noticed your postings, and I fully agree with you, but with all respect, in my humble opinion nowadays it *is* a dumpyard
Sep 19 20:05:19 <eFfeM> khem, btw meanwhile had a quick peek at the buildroot git: the major advantage they have compared to us, is that they only have *one* version of every package (which greatly simplifies things)
Sep 19 20:07:09 * eFfeM wished OE had that too; it still escapes me why we need 6 abiwords or 12 ti-xdctools or 11 gtk+ recipes, with hardly anyone (if any) knowing why we have these version and what the difference is between them
Sep 19 20:07:20 <khem> eFfeM: btw the python patch you posted is interesting
Sep 19 20:07:49 <eFfeM> khem, not sure if python-dev should be removed or replaced by python, the patch removes it
Sep 19 20:07:51 <khem> eFfeM: because we build modules we might not depend on python-dev but instead on python-native-dev or something
Sep 19 20:08:14 <khem> it should certainly depend/rdepend on python
Sep 19 20:08:16 <eFfeM> khem, that is interesting, didn't think of that
Sep 19 20:09:18 <eFfeM> guess it should depend, actually that is what dragged in libc6-dev in my image (which I mentioned a few days ago)
Sep 19 20:09:28 <khem> scope of OE is lot bigger
Sep 19 20:09:41 <khem> I get it why we have many version
Sep 19 20:11:24 <eFfeM> i can imagine that for some recipes it makes sense to have multiple versions, but in a lot of cases I don't understand it at all, sometimes I feel it is just lazyness
Sep 19 20:11:49 <eFfeM> khem, btw will you be coming to elfc and oedem ?
Sep 19 20:17:07 <Unhelpful> is there a way to see exactly how configure or make is called by a recipe? i imagine bitbake -e if i know the right variable...
Sep 19 20:23:55 <eFfeM> khem, btw do you feel like running my script (contrib/clean-recipe on the gcc dir yourself) ?
Sep 19 20:24:03 <kergoth_> I like the idea of using BBVERSIONS for multiple versions, rather than a .inc with inclusion -- then everything is in one place at a glance, less repository pollution -- still good to cut down on versions, but its still cleaner
Sep 19 20:24:12 <Unhelpful> ah, the do_FOO scripts :)
Sep 19 20:25:50 <eFfeM> kergoth, that avoids some of the clutter, but you would get something like SRC_URI_version += "file://xx.patch" as newer versions might have the patch already applied
Sep 19 20:26:16 <eFfeM> to some extend we already do that with the .inc file, although sometimes I feel they are abused
Sep 19 20:31:23 <kergoth_> yeah, there's no avoiding that if you want to retain multiple versions, just a question of wher eit is
Sep 19 20:31:39 <kergoth_> .inc usage seems like a pattern of sorts, a kludge around a weakness in the format
Sep 19 20:34:23 <Unhelpful> or a valid way to consolidate the common components of recipes that build different versions of the same thing?
Sep 19 20:36:13 <eFfeM> the idea is probably that it should consolidate commonalities, but sometimes it is taken so far that even things like DESCRIPTION are put in the .inc file (which IMHO is better placed in the .bb files)
Sep 19 20:44:40 <kergoth_> Unhelpful: did I say it was invalid? no.  but you end up doing the exact same things every time
Sep 19 20:54:45 <khem> kergoth: I am in favor of BBVERSIONS atleast it will bring down parsing cost
Sep 19 21:01:58 <eFfeM> true
Sep 19 21:37:28 <eFfeM> calling it a day
Sep 19 21:37:40 <eFfeM> cya tomorrow
Sep 19 21:46:42 <Unhelpful> kergoth_: fair enough :)
Sep 19 21:48:03 <Unhelpful> perhaps the right solution for my problem lies in ensuring that native_* are used to install libraries and headers for gcc-cross-intermediate?
Sep 19 21:51:47 <Unhelpful> sysroot_stage_all in cross.bbclass is commented as though it might be relevant, too. # Override the default sysroot staging copy since this won't look like a target system
Sep 19 21:52:06 <Unhelpful> seems like the place to handle "target layout differs from what cross tools might expect"
Sep 19 21:56:40 <kergoth_> khem: hmm, wonder if lack of -i is a deal breaker for bumping oe minimum bitbake version, or if we can get that discussion started
Sep 19 22:15:21 <khem> kergoth_: I have seen few times people asking for bitbake -i
Sep 19 22:15:47 <kergoth_> course, the stupid thing is, itd probably take like a day at most to write a new ui to reimplement -i, just never seem to get around to it..
Sep 19 22:15:48 <khem> so I have little inclination towards it being working
Sep 19 22:15:49 <kergoth_> heh
Sep 19 22:16:16 <khem> hmm 
Sep 19 22:16:25 <kergoth_> i see it being of limited usefulness since its not a full shell.  i'd much rather see a shell with bitbake commands as scripts that talk to the running bitbake server
Sep 19 22:16:32 <khem> I guess throw something in
Sep 19 22:18:23 <khem> kergoth_: hmm talking to bitbake server is also a good option 
Sep 19 22:18:42 <kergoth_> to do that we'd have to change the default to use xml/rpc rather than the 'none' server, but i think itd be very useful
Sep 19 22:18:56 <khem> I think so too
Sep 19 22:19:04 <kergoth_> do something like how ssh does it, set an env var pointing at the running process, or a pipe to the process
Sep 19 22:19:25 <kergoth_> then have a little python script that runs the os.path.basename(sys.argv[0]) bitbake command, and symlink em
Sep 19 22:19:52 <khem> to connect to bb server ?
Sep 19 22:20:24 <kergoth_> yeah
Sep 19 22:20:53 <kergoth_> cd `peek nano S`
Sep 19 22:20:57 <kergoth_> or something, would be awesome
Sep 19 22:21:45 <khem> ok I see
Sep 19 23:12:49 <khem> hey grg
Sep 19 23:12:55 <grg> hi khem 
Sep 19 23:13:04 <grg> how's things?
Sep 19 23:15:26 <khem> ok,
Sep 19 23:15:31 <khem> I have got a bigger HD now
Sep 19 23:15:38 <khem> so hoping my bitbake world will complete this time
Sep 19 23:16:27 <grg> :)
Sep 19 23:16:42 <grg> i still haven't gotten one to complete
Sep 19 23:17:40 <grg> gets to about task 50000 quite a lot, before something causes bitbake to exit. Its been a few different things so far
Sep 19 23:18:57 <khem> yes bitbake bails out on me too
Sep 19 23:20:14 <khem> but then I start it again and it continues
Sep 19 23:20:57 <khem> someone installs <sysroot>/usr/lib/crt1.o after glibc
Sep 19 23:21:29 <khem> but this is crt1.o: Mach-O object acorn
Sep 19 23:21:41 <khem> so obviously everything after that will fail
Sep 19 23:21:44 <grg> yeah, i got that before. Its part of the iphone toolchain
Sep 19 23:21:54 <khem> oh nice
Sep 19 23:22:07 <grg> apple-csu_0.30.bb
Sep 19 23:22:07 <khem> we should exclude it from world
Sep 19 23:22:40 <grg> the recipe needs to bit hit with a sharp maintenance stick
Sep 19 23:22:47 <grg> s/bit/be/
Sep 19 23:23:22 <khem> log.do_install.20098:/scratch/oe/sysroots/x86_64-linux/usr/bin/install -c crt1.o dylib1.o bundle1.o crt0.o /scratch/oe/work/armv7a-oe-linux-gnueabi/apple-csu-0.30-r0/image/usr/lib
Sep 19 23:23:25 <khem> hmmm
Sep 19 23:23:46 <khem> who added it
Sep 19 23:24:29 <grg> dunno, but you're the last one to commit to the file :P
Sep 19 23:25:31 <khem> my changes were more of a global nature
Sep 19 23:25:45 <khem> Jeremy Laine
Sep 19 23:25:50 <khem> is one who added this stuff
Sep 19 23:26:00 <khem> I just fixed autotools stuff
Sep 19 23:27:21 <khem> grg: I am going to exclude it from world build with a hammer approach
Sep 19 23:28:37 <grg> khem, sure. I suspect that its an unusable recipe and can be moved to obsolete.
Sep 19 23:31:53 <khem> grg: conf/distro/iphone-compat.conf
Sep 19 23:33:28 <grg> khem, We need a COMPATIBLE_DISTRO option too?
Sep 19 23:36:54 <khem> actually that iphone stuff should have been done on more top level
Sep 19 23:37:41 <khem> somehwere  we have to say enough of crap
Sep 19 23:37:56 <khem> OE's belly is fat enough
Sep 19 23:39:24 <grg> Yes. I suspect oe is not going to get a rewrite, like most applications have the luxury of.
Sep 19 23:39:52 <grg> i suppose poky is the closest thing to that
Sep 19 23:42:22 <khem> yes shed some weight 
Sep 19 23:42:45 <khem> I am in favor of making OE more agile and dev friendly
Sep 19 23:44:19 <CIA-68> 03Khem Raj <raj.khem@gmail.com> 07master * r3d7a670334 10openembedded.git/recipes/fam/ (fam-2.7.0/gcc4-fixes.patch fam_2.7.0.bb): 
Sep 19 23:44:19 <CIA-68> fam_2.7.0.bb: Fix compilation with gcc4
Sep 19 23:44:19 <CIA-68> Signed-off-by: Khem Raj <raj.khem@gmail.com>
Sep 19 23:44:24 <CIA-68> 03Khem Raj <raj.khem@gmail.com> 07master * r0319f88785 10openembedded.git/recipes/iphone/ (3 files): 
Sep 19 23:44:24 <CIA-68> iphone: Exclude from world.
Sep 19 23:44:24 <CIA-68> apple-csu overwrites the C startup files and nothing works after that
Sep 19 23:44:24 <CIA-68> we can not select them with normal linux toolchain being staged and
Sep 19 23:44:25 <CIA-68> used
Sep 19 23:44:25 <CIA-68> Signed-off-by: Khem Raj <raj.khem@gmail.com>
Sep 19 23:45:09 <khem> grg: another issue I saw was that I selected eglibc but somehow after a while it also compiled glibc 
Sep 19 23:45:17 <khem> I wonder who demands glibc only
Sep 19 23:45:35 <khem> as eglibc should provide all packages that glibc provides
Sep 19 23:46:11 <grg> khem, do you have any plans for future removal of glibc recipes?
Sep 19 23:46:32 <grg> it seems they are (should be) redundant
Sep 19 23:46:47 <khem> grg: I do but many distro's still use them
Sep 19 23:47:04 <khem> and many dev's just dont understand the eglibc infact is glibc
Sep 19 23:47:16 <khem> they view it as annother C library like uclibc
Sep 19 23:47:29 <khem> which is not the case
Sep 19 23:51:45 <khem> right now I am struggling to get mips64 into OE
Sep 19 23:52:27 <khem> I have it working but OE's understanding of multilib is poor
Sep 20 00:06:06 <dj-death> who is using mips64 ? :)
Sep 20 00:06:33 <dj-death> same question for sh5 :)
Sep 20 00:12:31 <khem> dj-death: is there sh5
Sep 20 00:12:47 <khem> dj-death: and mips64 I expect octeon and xlr folks
Sep 20 00:13:10 <khem> and if we have sample implementation people who are interested will consider OE
Sep 20 00:13:41 <khem> dj-death: and OE for sh is used by reneras 
Sep 20 00:13:46 <khem> renesas
Sep 20 00:14:51 <khem> ka6sox: hi
Sep 20 00:15:03 <ka6sox> hi
Sep 20 00:15:16 <khem> ka6sox: I was trying to revive bugzilla
Sep 20 00:15:30 <khem> somehow I think its apache issue may be 
Sep 20 00:16:05 <ka6sox> could be....
Sep 20 00:16:06 <khem> http://bugzilla.openembedded.org/ shows the list of files which it should have executed the CGI scripts
Sep 20 00:17:13 <ka6sox> okay let me look in a few...just got back...kinda dusty and need a shower.
Sep 20 00:19:03 <khem> ka6sox: sure how was it btw
Sep 20 00:19:08 <khem> and where did you camp
Sep 20 00:19:40 <ka6sox> khem, cachuma lake
Sep 20 00:19:54 <ka6sox> it was very nice...fog came in too early IMHO.
Sep 20 00:20:04 <ka6sox> so the viewing was short but sweet
Sep 20 00:23:16 <khem> ka6sox: is it towards solvang ?
Sep 20 00:24:29 <ka6sox> khem, yep
Sep 20 00:24:35 <ka6sox> near there
Sep 20 00:25:32 <ka6sox> khem, I use OE to control my telescope.
Sep 20 00:26:08 <khem> ka6sox: I think I have been there IIRC
Sep 20 00:26:20 <khem> during 2008 summer
Sep 20 00:26:31 <khem> ka6sox: control telescope
Sep 20 00:26:34 <khem> interesting
Sep 20 00:27:08 <ka6sox> yes, it controls the mount and takes the pictures, as well as monitoring weatehr.
Sep 20 00:27:11 <ka6sox> er weather.
Sep 20 00:27:22 <khem> nice
Sep 20 00:27:36 <khem> what processor is in use in there
Sep 20 00:28:09 <ka6sox> IXP425(X3)currently....new is Marvell Kirkwood (single)
Sep 20 00:28:39 <ka6sox> (3 Slugs vs 1 OpenRD client)
Sep 20 00:30:21 <ka6sox> the slug issue was not enough RAM.
Sep 20 00:49:59 <khem> cool
Sep 20 01:06:24 <fidencio> A very noob question. I build one package using bitbake. Where's the pakcage, after build
Sep 20 01:06:27 <fidencio> ?
Sep 20 01:46:50 <grg> fidencio[AWAY], have a look in your tmp dir, under "deploy"
**** ENDING LOGGING AT Mon Sep 20 02:59:57 2010