**** BEGIN LOGGING AT Sun Dec 16 03:00:02 2007 Dec 16 03:22:57 hola Dec 16 05:12:03 anyone awake? Dec 16 05:37:43 not anymore... (-; Dec 16 05:44:34 dang Dec 16 05:45:07 having a heck of a time building a prop qemu oe image that boots Dec 16 06:52:32 what's a good name for a minimal image plus ipkg support? Dec 16 06:54:00 minimal-ipkg-image Dec 16 07:01:29 cd Dec 16 07:33:59 hi... if i need different configure options than defined in a .bb what would be the right way to do so? copy the db and edit and build with that? Dec 16 07:34:17 s/db/bb/ Dec 16 09:25:56 03openmoko 07org.oe.dev * r7eb3dab6... 10/ (1 packages/openmoko-spaces/openmoko-toolchain-scripts_svn.bb): change to rev 3630. Dec 16 09:26:02 03john_lee 07org.oe.dev * r94968724... 10/ (1 classes/sourcepkg.bbclass): fix sourcepkg minor error. make it possible to inherit in .bb Dec 16 09:26:07 03john_lee 07org.oe.dev * r215866d8... 10/ (1 conf/distro/include/moko-autorev.inc): Dec 16 09:26:07 patch moko-autorev.inc to reflect the removal of OM2007 in svn Dec 16 09:26:07 by comment out the obsolete items. Dec 16 09:26:12 03john_lee 07org.oe.dev * r7e3f4ca6... 10/ (1 conf/distro/include/moko-autorev.inc): missed SRCREV_pn-openmoko-panel-demo ?= "${AUTOREV}" Dec 16 09:26:18 03john_lee 07org.oe.dev * r69f73a39... 10/ (3 files in 3 dirs): fix bugzilla #882 Dec 16 09:26:25 03rwhitby 07org.oe.dev * r12e7afc8... 10/ (1 packages/images/base-image.bb): base-image: New image designed to be a basis upon which you can install any other desired functionality using task packages from feeds. Dec 16 09:28:17 Who is John Lee? Dec 16 09:28:33 03rwhitby 07org.oe.dev * re52ae810... 10/ (1 packages/images/base-image.bb): base-image: Added more documentation, including criteria for adding and removing packages from the image. Dec 16 09:28:55 fix bugzilla #882 is a bit short, especially if the OE bugtracker says the bug has been fixed more than a year ago Dec 16 09:28:58 Laibsch: that's me merging in changes from the openmoko stable monotone repo Dec 16 09:29:24 So, openmoko bugzilla? Dec 16 09:29:27 John Lee is the openmoko distro manager. Dec 16 09:29:50 yes, I presume it's openmoko bugzilla. Dec 16 09:31:00 I guess we need to make it clear to people comitting to org.openembedded.dev that their commit comments must be reasonable for any OE developer to read, not just their distro developers. Dec 16 09:33:14 Yes Dec 16 09:33:22 But I thought you were the one making the commits? Dec 16 09:33:26 rwhitby: good idea. also prefixing the short commit message with the package recipe/topic like we do would be great. Dec 16 09:33:52 pH5: the prefix is already part of the commit message policy Dec 16 09:34:12 so anyone using the org.openembedded.dev branch must comply with that policy (e.g. I make sure nslu2-linux people do) Dec 16 09:34:12 rwhitby: exactly, but r69f73a39... doesn't honor that policy. Dec 16 09:34:37 pH5: agreed - we need to ask mickey_away to educate john_lee Dec 16 09:36:10 Laibsch: I sync against both OE and openmoko monotone repositories. This commits are by john_lee, not me. I'm just the conduit by which the org.openembedded.dev branch was synced between the separate servers (since openmoko chooses on only sync once a week after making sure their distro builds first) Dec 16 09:36:47 (to be exact, I sync against monotone.openembedded.org, and pull-only from monotone.openmoko.org) Dec 16 09:57:47 morning all Dec 16 09:58:02 morning rp Dec 16 10:08:11 03rwhitby 07org.oe.dev * rc4c17ca8... 10/ (4 files in 3 dirs): angstrom/build-release: Instead of building a useless nslu2-minimal-image, build a minimal-image plus a useful nslu2-base-image. Dec 16 10:09:59 morning RP Dec 16 10:11:37 good morning RP Dec 16 11:37:53 RP hi there Dec 16 11:38:54 just read you mail about the ENV stuff.. what about a switch in local-conf which can be set to ignore anything but a short useful and documented whitelist of user env settings Dec 16 11:39:51 meaning USE_USER_ENV = 'no' could be set by mokomakefile on setup by default and regular users not having such problems as raster described Dec 16 11:41:35 i dunno really how OE handles this, but i see the major feature of oe in beeing independant of a host system to the most possible degree, giving reproducible results. which means it should not link against anything in the host nor use stuff which it not is explicitely allowed by ASSUME_PROVIDED or how it was called Dec 16 12:11:05 * * OE Bug 3481 has been created by  Dec 16 12:11:07 * * libsdl-qpe and libsdl-x11 conflict with each other Dec 16 12:11:09 * * http://bugs.openembedded.org/show_bug.cgi?id=3481 Dec 16 13:20:10 YES! Dec 16 13:20:46 moin Dec 16 13:22:55 I'm building for an SH3 (133MHz) 16-32MB machine, and I cannot generate binary locales, neither does qemu have an SH3 module. Dec 16 13:23:19 But, I'm getting an SH3 devboard, and I was hoping I could generate the binary locales there. Dec 16 13:23:24 Can I do that with OE? Dec 16 13:24:17 B_Lizzard: with enough ram you can do that Dec 16 13:24:30 Hmmm, it has 64MB... Dec 16 13:24:33 Not enough, eh? Dec 16 13:24:41 B_Lizzard: you can always sawp :) Dec 16 13:24:54 hehe Dec 16 13:25:40 I just want ready made binary locales for the users, even if it takes 5 days compiling on the devboard Dec 16 13:26:32 I just want to know if OE will attempt to compile them on the host device if the architecture is the same or if a configuration thing is set. :) Dec 16 13:27:06 As opposed to passing them through qemu, or leaving them for the target device Dec 16 13:27:18 B_Lizzard: I don't know but I think if you disable binary locale generation, they will be generated when installed on the system Dec 16 13:28:03 Yeah, that's what I currently have going...which means users can't have locales, since the target device is way too underpowered... Dec 16 13:28:22 I'll check binary locale generation once I get the devboard, then. Dec 16 13:28:35 See if I can disable passing it through qemu Dec 16 14:40:33 how does one enable locale generation for only one language? Dec 16 14:43:39 Well, on the host machine or with qemu? Dec 16 14:44:04 I mean on the target machine or with qemu on the host machine Dec 16 14:47:12 B_Lizzard: I mean the setting in conf/local.conf which disables generation of locales Dec 16 14:47:21 I only need english locales Dec 16 14:48:23 You either build them all on your machine or leave them to be generated on the target machine, I think. Dec 16 14:48:54 If you want to leave them for the machine, you can of course choose which ones you want to ship with your image Dec 16 14:49:07 IMAGE_LINGUAS I think it is. Dec 16 14:49:59 (leave them for the target machine, that is) :) Dec 16 14:52:48 ok thanks Dec 16 14:53:16 No problem :) Dec 16 15:08:19 huhu Dec 16 15:26:14 bonjour Dec 16 16:17:14 hello Dec 16 16:21:49 yo Pryan :) Dec 16 16:26:07 hi... if i need different configure options than defined in a .bb what would be the right way to do so? copy the db and edit and build with that? Dec 16 16:30:09 03pfalcon 07org.oe.dev * rcf886658... 10/ (1 classes/package_ipk.bbclass): Ability to write ipk's depends on ipkg-utils-native having been staged. Dec 16 16:44:33 hi Dec 16 16:49:49 how is the installation of OE ? Dec 16 16:50:19 i have downloaded a .mnt file and i dont know how to use it Dec 16 16:50:30 read getting started ... Dec 16 16:51:28 where ? Dec 16 16:52:04 http://www.openembedded.org/wiki/GettingStarted Dec 16 16:52:07 here ? Dec 16 16:52:35 yeah Dec 16 18:26:03 roh: The problem is in bitbake, not OE. bitbake is not the right place to maintain a whitelist and there are some variables such as PATH which need this behaviour so it can't be disabled outright hence my suggestion that the environment script handles this (or things like the OM makefile I guess) Dec 16 18:26:12 RP!! Dec 16 18:26:17 was looking for you for quite a while :) Dec 16 18:26:39 you were doing work on the meta toolchain stuff? Dec 16 18:27:33 Jin^eLD: hi! Yes, I work on the meta-toolchain Dec 16 18:27:45 RP: I found a lot of weirdness around the meta-toolchain package Dec 16 18:28:06 one thing really makes no sense... when building meta-toolchain something is pulling in external-toolchain Dec 16 18:28:23 i.e. something forces the build of the external-toolchain.bb, I tried -DDD but still could not figure out who or what does that Dec 16 18:28:33 bitbake gave no clues in its output about why it might be doing that? Dec 16 18:28:36 the funny thing - if you simply remove the external-toolchain.bb then it builds Dec 16 18:28:54 exactly, I could not find any clues about why it is being built Dec 16 18:28:58 Thats more expected than funny... Dec 16 18:29:24 well, why? I'd assume that if it "needs" to built it, that it would complain about it not being there if I remove it Dec 16 18:29:28 Try removing "provides" entries from meta-toolchain until you find the one responsible... Dec 16 18:29:38 ok Dec 16 18:30:05 another thing is about packaging of the toolchain Dec 16 18:30:09 external-toolchain is providing something meta-toolchain wants. The first job is to identidy what, the second is to find out why something else isn't a higher prority in providing it Dec 16 18:30:57 I'll try what you suggested, about the provides.. Dec 16 18:31:04 now, when I unpack the generated sdk tar.bz2 Dec 16 18:31:07 I get several strange things Dec 16 18:31:19 Are you sure bitbake never says "consider defining xyz" ? Dec 16 18:31:31 some PREFERRED_PROVIDER? Dec 16 18:32:00 RP: I will have to recheck, maybe I missed it, but I remember looking through the -DDD output, but then I was looking for something that would select external-toolchain Dec 16 18:32:03 and that I could not find Dec 16 18:32:13 anyway, I will have another look there, will follow the clue you gave me Dec 16 18:32:18 so back to the generated output.. Dec 16 18:32:31 I defined my prefix to be "/opt/bco" Dec 16 18:32:48 now, when I unpack the sdk.tar.bz2 Dec 16 18:33:04 in the root of the package there is opt as specified, then there is an empty /usr Dec 16 18:33:19 and then there is an empty home/jin/openembedded/trunk/build/bco/work/i686-arm-sdk-angstrom-linux-gnueabi/meta-toolchain-sulu-1.0-r0/sdk/image/usr/lib/ipkg/lists/ Dec 16 18:33:23 This has been mentioned before. I don't know why that happens Dec 16 18:33:36 (the /usr) Dec 16 18:33:44 yeah, I remember the usr thing, but the home thing is new Dec 16 18:33:52 The /home/... sounds even more broken :/ Dec 16 18:33:55 yes Dec 16 18:34:01 now, if from there I go to /opt/bco/arm Dec 16 18:34:04 and do my ls Dec 16 18:34:07 I have a home there again! Dec 16 18:34:26 same path structure as above, just in a different place now Dec 16 18:34:45 Someone needs to debug it... Dec 16 18:35:04 I need more pointers I guess Dec 16 18:35:19 if you tell me more about the toolchain generation process I could try to figure out what is happening Dec 16 18:35:41 oh, and one more question.. is the generated toolchain hardcoded to some specific path or can it be freely relocated once produced? Dec 16 18:35:41 Are those paths being created by the packages that make up meta-toolchain or the commands in meta-toolchain/bb itself? Dec 16 18:35:54 Jin^eLD: Its hardcoded and can't be moved Dec 16 18:36:18 I am not sure who makes them (regarding the home paths) Dec 16 18:36:28 ok, you need to work that out Dec 16 18:36:38 btw one more question Dec 16 18:36:46 is pkgdata supposed to be there? Dec 16 18:36:52 Either they're in some .ipk or they're created by the commands in meta-toolchain.bb Dec 16 18:36:53 there is a pkgdata directory with stuff in it Dec 16 18:36:58 yes, pkgdata is meant to be there Dec 16 18:37:03 what is it good for? Dec 16 18:37:27 So you can use the external toolchain with OE to make builds shorter Dec 16 18:37:49 ah, that's what the "external-toolchain" package is for? Dec 16 18:37:54 right Dec 16 18:38:09 ok.. so if I plan to give it out to people who for some reason do not work with OE, I can safely remove that? Dec 16 18:38:21 would be nice to have it configurable for such cases Dec 16 18:39:47 Yes, you can remove it. Its not that big so I've worked on the theory that it was better to make it suitable for general use rather than specialised Dec 16 18:40:09 Jin^eLD: Lets settle on fixing the bugs before we try and add in more special case code? ;-) Dec 16 18:40:25 hehe, yeah, good idea :> Dec 16 18:40:58 there was one more weird thing, a collegue tried to build stuff using the produced toolchain Dec 16 18:41:10 and he got: cc1plus: error: Dec 16 18:41:19 /home/jin/openembedded/trunk/build/bco/work/i686-arm-sdk-angstrom-linux-gnueabi/ Dec 16 18:41:24 gcc-cross-sdk-4.1.2-r10/sysroot/opt/bco/arm/local/include: Dec 16 18:41:32 Permission denied (which is obvious, since my home is not open) Dec 16 18:41:37 but why would cc1plus search for stuff there? Dec 16 18:41:59 is there something more that went wrong during toolchain generation? Dec 16 18:42:01 A bug somewhere in the toolchain generation :( Dec 16 18:42:05 doh Dec 16 18:42:22 It shouldn't do that... Dec 16 18:42:46 any idea where that comes in or what it is? Dec 16 18:42:55 no :/ Dec 16 18:43:02 not with just the above anyway :/ Dec 16 18:43:03 I spent quite some time trying to figure out, was reading various guides but had to give up in the end Dec 16 18:43:39 I am not sure how florian's build went, he also started one to check if he gets the same results as me Dec 16 18:43:39 I really wish I had more time to help but I have a ton of other issues I need to address too :( Dec 16 18:43:43 but he also had no further clues Dec 16 18:44:07 Its all complicated by the fact poky has made the sysroot changes too :/ Dec 16 18:44:40 well, you already gave me some pointers, I think I will be able to solve the homedir creation thing and also the provides/external-toolchain thing Dec 16 18:44:58 That would be good :) Dec 16 18:45:01 so some pointers from time to time might be enough for the start Dec 16 18:45:04 I'll try and give pointers where I can... Dec 16 18:45:09 thanks Dec 16 18:45:21 oh and one more thing, actually there is even a PR for it Dec 16 18:45:51 I'll be back ~30 mins Dec 16 18:46:00 that was an easy fix, but the PR is still open Dec 16 18:46:01 ok Dec 16 18:48:52 RP: if you can have a quick look, solution is posted, just needs to be added and commited http://bugs.openembedded.org/show_bug.cgi?id=2482 Dec 16 19:09:19 Jin^eLD: back, that fix looks sane Dec 16 19:10:27 binutils.inc is the wrong place though as its sdk specific Dec 16 19:11:08 oh ok Dec 16 19:11:18 could you add it? Dec 16 19:13:19 Yes, although I should really test it... Dec 16 19:14:22 indeed... Dec 16 19:22:27 Jin^eLD: I'll try and have a look at that later on Dec 16 19:22:57 ok, thanks Dec 16 19:53:03 RP: Since you are the last to make changes to meta/package-index.bb; Does "bitbake package-index" include ipk from the deploy dir but where there is no corresponding stamp in the work dir? Dec 16 19:53:31 When I clean $TMPDIR, I usually preserve the deploy directory Dec 16 19:54:06 My impression is that those old ipk do not make it into the new Packages.gz Dec 16 19:59:34 Laibsch: Any ipks in the deploy directory should make it into the index Dec 16 20:00:13 Really? Dec 16 20:00:18 I am glad it should Dec 16 20:00:26 I was under the impression they don't always Dec 16 20:00:40 I've never seen that not happen fwiw Dec 16 20:00:41 But I never looked into it carefully Dec 16 20:00:47 OK Dec 16 20:00:59 I will pay a bit more attention next time Dec 16 20:01:17 But since it should be the behaviour I was hoping for everything should be fine Dec 16 20:41:05 * * OE Bug 3265 has been RESOLVED (FIXED) by Dec 16 20:41:07 * *  Update the version of glibmm library Dec 16 20:41:08 * * http://bugs.openembedded.org/show_bug.cgi?id=3265 Dec 16 21:02:20 Is there an SDL port for OE? Dec 16 21:09:24 morning Dec 16 21:09:32 zap: OE can build SDL for years Dec 16 21:10:29 Ah God, was looking at OE tree from 2004... sorry for dumb question :) Dec 16 21:13:14 even 2004 was able ;) Dec 16 21:13:33 indeed, it's called libsdl, I was looking for SDL :) Dec 16 21:14:08 the guys with pdaXrom say they have some patches that makes SDL substantially faster Dec 16 21:16:55 zap: faster on 2.4 or 2.6-pdax? Dec 16 21:17:03 and for how old version? Dec 16 21:17:22 I think it doesn't matter, I think they updated SDL_Blit() for faster scaling Dec 16 21:17:27 but I have to see yet Dec 16 21:17:38 I mean they implemented scaling in arm asm Dec 16 21:18:49 zap: If you can point to any patches, I think your best bet is to open a bug to track this Dec 16 21:19:03 yeah Dec 16 21:38:02 bye Dec 16 22:57:04 * * OE Bug 2482 has been RESOLVED (FIXED) by rpurdie(AT)rpsys.net Dec 16 22:57:06 * *  binutils-cross-sdk: non debug package contains .debug directory Dec 16 22:57:08 * * http://bugs.openembedded.org/show_bug.cgi?id=2482 Dec 16 22:59:15 03rpurdie 07org.oe.dev * r8ffce910... 10/ (1 packages/binutils/binutils-cross-sdk_2.18.bb): binutils-cross-sdk-2.18: Sync debug packaging fix from Poky (also #2482) Dec 16 23:01:42 bitbake openmoko-devel-image , making wrong dependecies tree - trye to compile linux-openmoko before u-boot-mkimage-openmoko-native Dec 16 23:17:15 hi all Dec 16 23:19:07 yop flo_lap :) **** ENDING LOGGING AT Mon Dec 17 02:59:57 2007