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