**** BEGIN LOGGING AT Sat Sep 03 02:59:57 2011
Sep 03 18:36:21 <lumag_> hi all
Sep 03 21:27:17 <lumag_home> bluelightning, here?
Sep 03 21:29:01 <bluelightning> hi lumag_home
Sep 03 21:31:34 <lumag_home> hi, bluelightning.
Sep 03 21:32:10 <bluelightning> what's up?
Sep 03 21:33:29 <lumag_home> I'm trying merge changes in meta-hh and meta-zaurus. Did you talk with Martin Jansa, whose layer will support om-gta phones?
Sep 03 21:35:03 <bluelightning> lumag_home: I haven't spoken with him directly recently but he has sent some patches to bring meta-hh up to date with changes in meta-zaurus, I guess you have seen those on the mailing list already?
Sep 03 21:35:24 <lumag_home> no. On which ml?
Sep 03 21:35:26 <bluelightning> I haven't had a chance to merge them yet but they look ok
Sep 03 21:35:32 <lumag_home> oe-core or oe-dev?
Sep 03 21:35:47 <bluelightning> oe-dev mailing list
Sep 03 21:36:06 * lumag_home have to start reading MLs continuously.
Sep 03 21:39:24 <lumag_home> bluelightning, sorry for the noise then.
Sep 03 21:40:33 <ant__> hi lumag, bluelightning
Sep 03 21:41:18 <bluelightning> lumag_home: no worries :)
Sep 03 21:41:21 <bluelightning> ant__: hi
Sep 03 21:41:30 <lumag_home> ant__, evening!
Sep 03 21:42:15 <ant__> I'm still wondering whether having linux-2.x only in meta-hh
Sep 03 21:42:29 <ant__> or only 3.x
Sep 03 21:42:46 <ant__> surely not both
Sep 03 21:43:06 <ant__> Zaurus 'should just work'
Sep 03 21:43:14 <lumag_home> ant__, that's a good idea, but in generic speak it won't work w/o really tight coordination.
Sep 03 21:43:53 <ant__> you mean RMK merging patches ?
Sep 03 21:44:07 <bluelightning> ant__: for zaurus th
Sep 03 21:44:08 <bluelightning> er
Sep 03 21:44:29 <bluelightning> ant__: for zaurus if we can offer full support with 3.x then we shouldn't have 2.x in there...
Sep 03 21:44:40 <bluelightning> but for other machines we'll have to keep it for now
Sep 03 21:45:04 <lumag_home> ant__, you just can't always rebase old patches to contemporary kernels.
Sep 03 21:45:23 <ant__> I see. is not giant leap for Zaurus to follow afterwards
Sep 03 21:45:32 <ant__> ah, still patches around.. :/
Sep 03 21:45:48 <lumag_home> sometimes something breaks the patches, sometimes kernel gains new features which conflict with your changes.
Sep 03 21:46:21 <ant__> I see, you talk mostly about collie/tosa, isn't?
Sep 03 21:46:55 <lumag_home> ant__, generic talk about kernels.
Sep 03 21:47:18 <ant__> sure, but now let's fly low low
Sep 03 21:47:27 <ant__> does collie somehow work?
Sep 03 21:48:06 <bluelightning> I haven't had a chance to re-test myself
Sep 03 21:48:48 <lumag_home> still no time to test. Currently fighting with qemu in my spare time.
Sep 03 21:48:52 <ant__> I tested only linux-kexecboot lately. on poodle the keymap-patch seems good cure
Sep 03 21:49:05 <ant__> but still power man is broken
Sep 03 21:50:43 <ant__> on clamsgells there is this strange kernel panic on boot sometimes
Sep 03 21:51:03 <ant__> but this should be solved once Russel merges
Sep 03 21:55:59 <ant__> ok, for the moment I'll let kernel apart and finish other things
Sep 03 21:57:20 <lumag_home> btw: should we become the upstream for zaurusd? Or someone should push a pile of patches back to git.yoctoproject.
Sep 03 21:57:47 <ant__> RP does not maintain it anymore
Sep 03 21:58:26 <ant__> do you remember the 'new' zaurusd ?
Sep 03 21:58:28 <ant__> http://metan.lindevdoc.org/git/?p=zaurusd.git/.git;a=summary
Sep 03 21:58:43 <ant__> can we merge the functionality together?
Sep 03 21:59:50 <ant__> see Stanislav's coment : http://paste.debian.net/128308/
Sep 03 22:00:32 <ant__> screen rotation in x is atm not working ifI'm not wrong
Sep 03 22:01:11 <ant__> audio sensing is optional/secondary stuff imho
Sep 03 22:01:27 <ant__> (at this point of development)
Sep 03 22:01:49 <bluelightning> I think RP would be happy for development to continue
Sep 03 22:02:15 <bluelightning> it may make sense to separate some of its functions
Sep 03 22:07:47 <lumag_home> bluelightning, there are 3 more patches to apply on top of what JaMa send to you. I've made a complete repo at git://github.com/lumag/meta-handheld.git
Sep 03 22:09:14 <lumag_home> ant__, Jay7 could you please try building images with that repo?
Sep 03 22:09:41 <ant__> that + meta-oe +oe-core
Sep 03 22:09:45 <ant__> ?
Sep 03 22:09:56 <lumag_home> yup.
Sep 03 22:10:04 <ant__> ok, no distro then
Sep 03 22:10:27 <lumag_home> btw: is there any analog to 'minimal' distro back in oe.org.dev times?
Sep 03 22:11:03 <ant__> afaik the defaults are for a minimal distro
Sep 03 22:11:38 <ant__> I build core-image-minimal
Sep 03 22:12:10 <ant__> and the size is a bit more than old 'minimal'
Sep 03 22:12:23 <ant__> minimal console-image I mean
Sep 03 22:12:48 <lumag_home> ant__, what do you set as a distro? defaults?
Sep 03 22:12:57 <bluelightning> lumag_home: ok I'll check it out
Sep 03 22:12:58 <bluelightning> thanks
Sep 03 22:13:17 <lumag_home> :)
Sep 03 22:13:18 <ant__> lumag: yes, it gives  http://paste.debian.net/128312/
Sep 03 22:13:24 <ant__> ah, pull bb
Sep 03 22:14:32 <ant__> bluelightning: I have to push klibc 1.5.24 -> 1.5.25  in meta-oe
Sep 03 22:14:37 <ant__> just one patch?
Sep 03 22:14:47 <ant__> or add , remove in 2 steps?
Sep 03 22:14:57 <ant__> we are the single users afaik
Sep 03 22:15:22 <lumag_home> I'm just sticking with angstrom, but it's big and somewhat incompatible with oe-core images. E.g. I've tried building qt4e-demo-image and got a broken image w/o busybox or other usefull things.
Sep 03 22:15:28 <lumag_home> ant__, git mv ?
Sep 03 22:15:46 <ant__> lumag: those asngstrom scripts need more debugging for themselves
Sep 03 22:15:53 <ant__> I don't trust them atm
Sep 03 22:15:59 <lumag_home> ant__, that's the usual procedure :)
Sep 03 22:16:19 <ant__> I mean about layer-crosstalking
Sep 03 22:16:43 <ant__> you risk to use an .inc from other layer
Sep 03 22:17:42 <ant__> btw I still don't understand why the zImage link in /boot is not done with oe-core
Sep 03 22:18:31 <ant__> lumag: iirc §
Sep 03 22:19:14 <ant__> iirc people in oe-core love those many-steps patches ;)
Sep 03 22:19:42 <lumag_home> strange
Sep 03 22:20:14 <ant__> maybe  I misunderstood but JaMa obliged me to do it lately
Sep 03 22:20:21 <ant__> even for meta-zaurus
Sep 03 22:22:36 <lumag_home> ant__, check the recent gdb, binutils upgrades in oe-core.
Sep 03 22:22:44 <lumag_home> They both do git mv thing
Sep 03 22:29:31 <lumag_home> ant__, I've checked the 'new' zaurusd. Frankly speaking I see no point in some parts of it's functionality.
Sep 03 22:32:51 <lumag_home> Regarding sound plugs. Probably zaurus has to be updated to use soc-jack infrastructure in kernel, so that we will be able to gain that for free.
Sep 03 22:33:39 <ant__> interesting
Sep 03 22:38:18 <lumag_home> bluelightning, I got a strange problem with libqpe-opie git version. Looks like something went wrong while downloading sources.
Sep 03 22:38:54 <bluelightning> lumag_home: I know fetching from gitorious can be unreliable at times :(
Sep 03 22:40:02 <lumag_home> I also got some complaints about opie-icon-reload not being available in git version :)
Sep 03 22:40:14 <bluelightning> yeah you can basically ignore that
Sep 03 22:40:31 <bluelightning> although really that should just be created and the warning will go away...
Sep 03 22:41:17 <lumag_home> strange. fetch doesn't download anything at all, but succeeds.
Sep 03 22:42:21 <ant__> a suggestion...
Sep 03 22:42:31 <ant__> should I follow debian 100% ?
Sep 03 22:42:34 <ant__> http://packages.debian.org/wheezy/armel/klibc-utils/filelist
Sep 03 22:42:57 <ant__> we have sh and sh.shared, kinit and kinit.shared
Sep 03 22:43:26 <ant__> debian only installs sh.shared but both kinit !?!
Sep 03 22:44:05 <ant__> I would put the shared in klibc-utils and the static in klibc-static-utils
Sep 03 22:44:10 <ant__> as rule
Sep 03 22:45:02 <lumag_home> Ah. I see.
Sep 03 22:45:03 <ant__> (issue is WARNING: For recipe klibc, the following files were installed but not shipped in any package:
Sep 03 22:45:03 <ant__> WARNING:   /bin/sh.shared
Sep 03 22:45:03 <ant__> WARNING:   /bin/kinit.shared)
Sep 03 22:45:57 <lumag_home> bluelightning, libqpe-opie.inc sets S to WORKDIR/library, but libqpe-opie_git should have S = WORKDIR/git, as that's the dir that I get
Sep 03 22:48:12 <bluelightning> lumag_home: this is a fetch2/fetch difference in behaviour
Sep 03 22:48:28 <lumag_home> bluelightning, how to overcome?
Sep 03 22:48:31 <bluelightning> many of the recipes have multiple git checkouts; for those to work it has to use different names
Sep 03 22:48:50 <bluelightning> just recently a patch was merged into bitbake to support that for fetch2
Sep 03 22:49:29 <bluelightning> annoyingly though I think it means changing all the git recipes :/
Sep 03 22:50:14 <lumag_home> So I should set BBFETCH2 somewhere?
Sep 03 22:50:54 <bluelightning> hmm, ok, so it's not a fetch2 thing...
Sep 03 22:51:43 <lumag_home> fetch2 has a destsuffix parameter
Sep 03 22:51:51 <lumag_home> But it isn't set in libqpe-opie
Sep 03 22:52:01 <bluelightning>  no, I guess that's the brand new option
Sep 03 22:52:54 <bluelightning> so we have two alternatives; patch fetch2 in bitbake to make subpath set destsuffix by default, or change all the git recipes to set destsuffix as well
Sep 03 22:53:09 <bluelightning> my preference would be for #1
Sep 03 22:53:33 <bluelightning> the good thing is afaik nobody else uses subpath so it should be OK to change its behaviour slightly
Sep 03 22:54:01 <lumag_home> bluelightning, yes, opie is the only user.
Sep 03 22:57:28 <lumag_home> bluelightning, what about this completely untested patch: http://paste.debian.net/128314/
Sep 03 23:00:31 <bluelightning> lumag_home: looks ok, try it :)
Sep 03 23:00:41 <lumag_home> trying right now.
Sep 03 23:01:36 <lumag_home> looks like it worked.
Sep 03 23:01:50 <lumag_home> what is the upstream for bitbake? RP himself? Or do they have some ML?
Sep 03 23:02:53 <bluelightning> lumag_home: there's a mailing list, bitbake-devel@lists.openembedded.org
Sep 03 23:17:14 <ant__> bluelightning: some oe change broke the packaging of klibc :/
Sep 03 23:17:26 <ant__> packages-split is now wrong
Sep 03 23:17:36 <ant__> now, referred to 17 august
Sep 03 23:17:44 <ant__> where it was ok
Sep 03 23:18:32 <bluelightning> hmm, that's strange... can you isolate the cause?
Sep 03 23:18:51 <ant__> hmm.. it's all around PACKAGES =
Sep 03 23:20:22 <ant__> doh...
Sep 03 23:20:28 <ant__> error: magic_load(ms, /usr/share/misc/magic) failed: File 5.4 supports only version 7 magic files. `/usr/share/misc/magic.mgc' is version 8
Sep 03 23:20:28 <ant__> rpmdeps: rpmfc.c:1154: rpmfcClassify: Assertion `mg != ((void *)0)' failed.
Sep 03 23:32:30 <bluelightning> ant__: well, you can be lazy for now and just switch to ipk of course
Sep 03 23:32:53 <ant__> afaik I'm using ipk :p
Sep 03 23:33:13 <bluelightning> why is it building rpms then...?
Sep 03 23:35:13 <ant__> is in log.do_package
Sep 03 23:46:22 <ant__> bluelightning: heh
Sep 03 23:46:49 <ant__> andrea@mizar /oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/share/misc $ file magic.mgc
Sep 03 23:46:49 <ant__> magic.mgc: magic binary file for file(1) cmd (version 7) (little endian)
Sep 03 23:46:49 <ant__> andrea@mizar /oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/share/misc $
Sep 03 23:46:49 <ant__> andrea@mizar /usr/share/misc $ file magic.mgc
Sep 03 23:46:49 <ant__> magic.mgc: magic binary file for file(1) cmd (version 8) (little endian)
Sep 03 23:47:30 <ant__> so the one in Sysroot is v7
Sep 03 23:47:43 <ant__> the one on buildhost/Genpp is v8
Sep 04 00:01:34 <ant__> rebuilding from scratch with meta-hh
Sep 04 00:01:36 <ant__> gn
**** ENDING LOGGING AT Sun Sep 04 02:59:57 2011