**** BEGIN LOGGING AT Sun May 17 02:59:57 2009 May 17 05:25:02 wow bitbake trunk badly woes :( May 17 05:25:25 03Roman I Khimov  07org.openembedded.dev * r6065fa491c 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): May 17 05:25:25 (e)glibc-package: set LD_LIBRARY_PATH on binary locale generation May 17 05:25:25 Locale generation might fail with SIGSEGV if host libs get messed with target May 17 05:25:25 libs, that might easily happen via /etc/ld.so.cache when building x86(_64) May 17 05:25:25 target on x86(_64) host. So explicitly specify LD_LIBRARY_PATH to prevent that. May 17 05:25:29 Acked-by: Tom Rini May 17 05:25:35 03Roman I Khimov  07org.openembedded.dev * r2b198cea9d 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): May 17 05:25:35 (e)glibc-package: enable binary locale generation on x86 and x86_64 May 17 05:25:36 Works well for this targets, so we can add that to BINARY_LOCALE_ARCHES May 17 05:25:38 whitelist. May 17 05:25:40 Acked-by: Tom Rini May 17 05:25:44 03Roman I Khimov  07org.openembedded.dev * r6d64144303 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): (log message trimmed) May 17 05:25:47 (e)glibc-package: fix kernel version passed to qemu May 17 05:25:49 Binary locale generation fails with May 17 05:25:51 FATAL: kernel too old May 17 05:25:53 if (e)glibc is configured for kernels newer than 2.6.16. This comes from May 17 05:25:55 kernel version check in sysdeps/unix/sysv/linux/dl-osinfo.h. We configure May 17 05:25:59 (e)glibc with "--enable-kernel=${OLDEST_KERNEL}", so to pass this check we May 17 08:25:37 ptitjes|party: I had a further look at the gobject stuff and its a world of pain :( May 17 08:54:51 As a warning to anyone, gobject-introspection works by creating a binary against target libs, then running it May 17 08:58:08 * RP suspects the only way around this will be qemu May 17 09:00:25 RP, hi ... what are u working on ? May 17 09:00:32 hi gremlin[it] May 17 09:00:50 gremlin[it]: In a moment of madness, making gobject-introspection work in poky May 17 09:02:31 ahhhh ... i try on my desktop with few success ... May 17 09:03:57 RP, i try in past to use OE with rpm packaging without success ... maybe i'll need your help soon May 17 09:09:52 gremlin[it]: for which architecture? May 17 09:10:49 RP, at now i'm making test on qemux86 target but i'll like to AVR32 and beagleboard ... May 17 09:12:07 gremlin[it]: rpm and yum are not very receptive to the idea of cross builds May 17 09:13:13 RP, i notice ... after some work i got rpm packages but on rootfs it fail seem it use some part of my host rpm/yum configs :( ... May 17 09:16:09 RP: can't you just make it link with the -native libs instead (and build with the native compiler, obviously)? May 17 09:16:26 I think the results of introspection should be independent of the target so it shouldn't matter which system you're running on. May 17 09:18:43 pb__: There appears to be type size information embedded in the data so I'm wary of that May 17 09:19:07 pb__: Also, it would mean building lots of things we don't currently have a -native for :/ May 17 09:20:29 ah, that's a nuisance May 17 09:27:32 hmm, and running this under qemu isn't quite as simple as it sounds May 17 09:29:17 mhh i trouble with keyboard and mouse in qemu ... ... damn May 17 09:30:05 gremlin[it]: This isn't the qemu system emulator, just the commandline one May 17 09:35:08 good morning May 17 09:40:24 hi Laibsch May 17 09:41:37 RP: I wonder why it's got that type size information in there. That seems like bad design: you'd think it would just be expressing the composite types in terms of the GObject fundamental types (in an abstract way) rather than concrete bit sizes. May 17 09:42:03 Using qemu would be a bit of a shame because you'd then be unable to build a (potentially quite important) set of packages for targets with no qemu support. May 17 09:42:26 pb__: I'm not 100% certain whether its doing anything nasty with the sizes or not yet May 17 09:42:59 pb__: Its the idea of requiring -native packages for the whole software stack that scares me :/ May 17 09:43:33 well, yeah, that'd be a bit annoying. But if we were to exhume your patch to build -native stuff transparently (without requiring a separate .bb file) then presumably it wouldn't be so bad. May 17 09:44:18 that said, though, I wonder whether you would actually need -native builds of the whole stack. presumably the introspection is just inspecting data structures, not actually running code from these libraries, so it mightn't matter if you linked the target libs even if you were planning to run on the build host. May 17 09:44:32 obviously that'd lose if the introspector wants to invoke constructors or whatever but I can't think why it would do. May 17 09:45:12 pb__: It looks like it runs code, I'm nnot sure why May 17 09:45:28 that is a bit weird. can you tell what code? May 17 09:46:09 pb__: Its linking some kind of xml data dumper around the librbary, then running it May 17 09:46:50 RP: yeah, that's how it gets at the type info, but I wouldn't have expected it to actually call any (non-trivial) function from the library in question. May 17 09:47:11 the only one I would have thought it has any business at all calling would be the class init function and I can't immediately think why even that would be useful. May 17 09:47:40 it probably does call a pile of stuff from GLib, but obviously we have a native build of that already. May 17 09:48:39 pb__: taking the example of glib, its trying to load a load of the gio modules May 17 09:49:02 Instead of the ones in staging, it then finds my /usr/lib/ ones May 17 09:49:34 and I'm only trying to do this on x86 64 bit building for 32 bit so I dread to think of the pain for something like arm May 17 09:50:17 Linking an x86 scanner around an arm lib doesn't sound like something the linker will like May 17 09:50:21 RP: glib is probably a bad testcase to start with because it will be hard to distinguish between what the "target-side" glib (i.e. the thing being introspected) is doing, and what the "host-side" glib (i.e. the supporting library used by the introspector itself) is doing. May 17 09:50:57 the linker probably will object to linking x86 code to arm without a bit of extra persuasion, but there's no fundamental reason it couldn't be done so long as the object formats are the same. May 17 09:51:17 admittedly you would lose there if you were building for non-elf targets (or on non-elf hosts), though. I guess that might be an issue for some folks. May 17 09:51:39 pb__: Its a bad testcase but kind of funamental to the package... May 17 09:51:40 folks with non-elf targets should just get with the programme :-} but I guess it's a bit harder to say that about non-elf build hosts. May 17 09:52:12 I already have a -native version which generates the the compiler/scanner and then patches the non-native version to use the native binaries May 17 09:52:29 RP: sure, what I meant is that it might be easier to start debugging it with a simpler library rather than trying glib straightaway. May 17 09:52:43 obviously it does have to work with glib in the end, but I think it'd be easier to understand the issues if you used something else. May 17 09:53:18 pb__: agreed May 17 09:53:38 * RP doesn't really have time to take this any futher, I'll just have to disable introspection :/ May 17 10:12:49 yah, probably the easiest solution for now May 17 10:19:31 * RP chokes May 17 10:19:39 this herbal tea is ghastly... May 17 10:27:16 heh May 17 10:27:35 RP: are you pregnant? May 17 10:33:51 pb__: Not that I was aware of... May 17 10:34:25 I was given some and decided I should at least try it. Which was a mistake. May 17 10:34:25 ah, just wondering what made you want to drink herbal tea May 17 10:34:30 heh, fair enough May 17 11:49:37 Hi May 17 11:49:57 I'm trying to push a few things to a personal, remote branch, but it fails: http://rafb.net/p/d9nFxm17.html May 17 11:50:17 What am I doing wrong? "git push oe" usually works when pushing to .dev May 17 12:01:20 Laibsch: What is the name of the local branch and what is the name of the remote branch you want to push to? May 17 12:01:58 Laibsch: I usually end up resorting to "git push oe localbranchname:refs/heads/remotebranchname" May 17 12:02:17 I have committed this locally to org.openembedded.dev but I want to create a personal branch remotely so that I can collaborate on the changes before actually pushing to org.oe.dev proper May 17 12:02:41 So the local branch is master? May 17 12:03:25 not sure May 17 12:03:35 It is the currently checked out branch May 17 12:03:57 But IIRC "git branch" colors the master green for me and it does not in this case May 17 12:04:06 Still so much to learn about git May 17 12:04:11 Laibsch: Try git push oe master:refs/heads/laibsch/scim May 17 12:04:18 thanks, I will May 17 12:05:15 http://rafb.net/p/N0MxKU64.html looks the same, still no luck May 17 12:05:44 got it May 17 12:06:01 git push oe org.openembedded.dev:refs/heads/laibsch/scim May 17 12:06:08 right :) May 17 12:06:14 thanks May 17 12:06:24 I was going to ask what the local branch was called if not master :) May 17 12:06:56 http://cgit.openembedded.net/cgit.cgi?url=openembedded/log/&h=laibsch/scim May 17 12:07:04 and it's where it should be May 17 12:13:32 03Rolf Leggewie  07laibsch/scim * r8d7669b1fe 10openembedded.git/conf/checksums.ini: checksums.ini: add scim 1.4.6 and 1.4.9 May 17 12:13:33 03Rolf Leggewie  07laibsch/scim * r2717d679f8 10openembedded.git/recipes/scim/ (scim.inc scim_1.4.9.bb): scim: create .inc and add 1.4.6 recipe May 17 12:18:44 03Rolf Leggewie  07laibsch/scim * rcfce543560 10openembedded.git/recipes/scim/scim.inc: scim: replace "sed;mv" with "sed -i" May 17 12:18:45 03Rolf Leggewie  07laibsch/scim * r8187795235 10openembedded.git/recipes/scim/scim_1.4.6.bb: scim: add 1.4.6 recipe May 17 12:23:19 * Laibsch is looking for help to understand why scim does not compile anymore 1.4.9: http://tinderbox.openembedded.net/packages/559772/ 1.4.6: http://tinderbox.openembedded.net/packages/559258/ May 17 12:24:01 at least 1.4.6 used to compile fine the last time I had tried. recipes are at http://cgit.openembedded.net/cgit.cgi?url=openembedded/tree/recipes/scim&h=laibsch/scim May 17 12:24:13 scim has thus far not been a part of OE May 17 12:25:55 uim is failing now, too: http://tinderbox.openembedded.net/packages/556977/ and that one is in OE and used to compile fine, too May 17 12:26:51 Laibsch: I looked but I don't know off hand. ltdl isn't anything to do with libtool is it? May 17 12:27:09 no idea May 17 12:27:11 ;-) May 17 12:27:17 thanks for looking May 17 12:27:53 could be a library May 17 12:28:03 google has libltdl among the first hits May 17 12:28:12 maybe I'm just missing a compile-time dependency May 17 12:28:37 but, yes, libtdl seems to be related to libtool May 17 12:28:47 We had a recent update, didn't we? May 17 12:29:19 Laibsch: For ltdl, we usually rip out the version in the package and make it use the shared one May 17 12:29:37 how do you do that? May 17 12:29:43 Some kind of flag? May 17 12:29:48 or serious patching? May 17 12:29:57 Laibsch: Er, usually serious patching :( May 17 12:30:04 darn May 17 12:30:19 I looked for patches in debian, but they don't seem to need them May 17 12:30:33 It might not be needed but its how I usually end up dealing with that problem :/ May 17 12:30:33 Does OE have a newer libtool than Debian? May 17 12:30:45 yes, libltdl is libtool's dynamic loader library. I think it basically wraps dlopen() in some crazy libtool way. May 17 12:30:46 Laibsch: out libtool usage is a bit different to debian May 17 12:30:58 ok May 17 12:30:58 s/out/our/ May 17 12:31:30 Laibsch: The "libtool" package should build a libltdl you can link against May 17 12:31:44 although I doubt I may be able to patch things, how would I approach it? May 17 12:31:50 some kind of HOWTO online? May 17 12:34:35 Laibsch: I just downloaded the source and took a look May 17 12:34:37 actually, looking at your logs, I don't think your scim problem is directly libtool related. May 17 12:34:38 It doesn't look so bad May 17 12:34:53 glad to hear that May 17 12:34:57 ltdl.cpp isn't a file that libtool ships, it's all written in c. this must be some scim-specific ltdl emulation. May 17 12:35:02 and thanks for taking a look May 17 12:35:04 pb__: ltdl.cpp is copied from libtool May 17 12:35:23 pb__: Its tied to the version of libtool the package is autoconf'd with I suspect May 17 12:35:33 RP: really? I didn't think libtool provided any c++ bits at all May 17 12:36:13 and method names like "scim::tryall_dlopen_module" sound like it must at least have been customised for scim rather than just a straight copy May 17 12:36:32 pb_: is this 1.4.9? May 17 12:36:47 pb__: You are indeed correct May 17 12:36:50 These Japanese guys unfortunately have a tendency do reinvent the wheel every time May 17 12:36:51 Laibsch: um, dunno, it's one of the links you posted. just a moment. May 17 12:36:58 yeah, 1.4.9 May 17 12:37:02 good May 17 12:37:09 that one is at least very recent May 17 12:37:24 Laibsch: So you need to fix the compile error, what I said above was wrong May 17 12:37:31 OK May 17 12:37:37 I think I'll post to the ml May 17 12:37:55 if I had to guess, I would say that you're just running into some compiler dialect problem and that this code was written for older gcc. May 17 12:37:57 It sounds complicated and I will certainly need quite a bit of help May 17 12:38:01 I think they took the ltdl.c from libtool and renamed it .cpp May 17 12:38:35 anyway, i think it needs debugging from first principles; I don't think you can trivially pull in a different ltdl from outside. May 17 12:38:36 You could try seeing how much they butchered it and if you could merge in bits of a more recent ltdl.c May 17 12:39:48 Is this something that they should be discouraged to continue doing? May 17 12:40:00 I'd certainly want to educate them where I can May 17 12:40:16 hey im having trouble bitbaking angstrom May 17 12:40:22 it keeps failing on binutils May 17 12:41:16 Laibsch: It would depend on why they did it May 17 12:41:31 OK May 17 12:41:43 has anyone possibly come across this before May 17 12:42:25 jayix: look at tinderbox.openembedded.net May 17 12:42:36 but I think binutils should generally build fine for most May 17 12:42:52 You can send your own reports for others to look at: http://wiki.openembedded.net/index.php/How_do_I_send_automatic_success_and_failure_reports May 17 12:43:10 thanks May 17 12:44:22 where can i find the more in detail log? not the one that the console pumps out May 17 12:45:18 Easiest way is to use tinderbox May 17 12:45:40 otherwise the path to the log should also be given on the console May 17 12:45:46 look among the last few lines May 17 12:46:20 http://tinderbox.openembedded.net/packages/binutils/ May 17 12:46:24 looks very good May 17 12:50:10 god there is some handy shit for linux May 17 12:50:39 almost makes up for things never working the first time May 17 12:50:43 thanks May 17 12:52:11 hehe May 17 13:43:15 CoreDump: any news on cdbot2? May 17 14:02:58 arg, I wonder how many addresses I can post to oe-dev at ..... May 17 14:19:52 loads, I expect. May 17 14:20:12 probably openembedded-devel@ every domain that serenity is configured to accept mail for May 17 14:28:07 yeah May 17 14:28:22 annoying in case we ever move the lists from ltg May 17 14:28:47 I suppose I'll see if I can figure out how resolve this May 17 14:54:39 it should be easy enough to fix, it's just a case of finding someone who's willing to make the changes. I think the lists used to be überhacker mickeyl's thing but I don't know who (if anybody) is looking after them nowadays. May 17 15:01:02 pb_, yeah I'll hunt around May 17 15:01:18 I think you can also post via the ltg addresses May 17 15:02:53 probably. I've never checked but my guess is that it'll accept anything in exim's local-domains list. May 17 15:07:33 lists.oe.org is CNAMED to oe.org May 17 15:07:52 without that the list doesn't work May 17 15:23:03 can anyone help me out, by telling me why the PR for this recipe (http://pastebin.com/m2748e504) is not picked up? OE always builds it as r0 ?!? May 17 15:54:38 sweetlilmre: OE builds as r0 only if PR isnt expicitly set, so this is surprising .I am just making a naive guess , but try adding -${PR} to the right of ${PV} in the SRC_URL ? May 17 15:55:10 rkirti: thanks I will give that a go now May 17 15:55:50 rkirti: won't that bork the src url tho? May 17 15:58:32 sweetlilmre: I am checking that out right now. It probably isnt the right way, but theres nothing else in the recipe where I detect something going wrong.. I am learning too.. May 17 15:58:58 rkirti: its fun isn't it :) if not a little frustrating at times! May 17 15:59:01 * Tartarus looks May 17 15:59:27 what error do you see? May 17 15:59:48 just that your output is r0 not r2? May 17 15:59:56 Tartarus: no error, just that if I bump the PR version to say "r1", OE still builds the packages as r0 May 17 16:00:23 Tartarus: which is frustrating... :) May 17 16:00:25 with current OE, right? May 17 16:00:31 PR for kernel is special May 17 16:00:40 kernel.bbclass now does: May 17 16:00:45 # A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force May 17 16:00:46 # rebuilds for kernel and external modules May 17 16:00:46 PR = "${MACHINE_KERNEL_PR}" May 17 16:01:11 and bitbake.conf does a soft (?=) assignment to r0 May 17 16:01:16 Tartarus: shouldn't that be: PR ?= "${MACHINE_KERNEL_PR}" May 17 16:01:26 seems backwards May 17 16:01:30 sweetlilmre, no, it's intended to be special like this May 17 16:01:45 So that external modules, and other stuff that depends on the kernel will be bumped May 17 16:02:07 Tartarus: so I should set MACHINE_KERNEL_PR in my machine conf then? May 17 16:02:21 if you need to go from r0 to r1, yes May 17 16:03:00 okay that is fine, as long as I can manage the versions. I assume it would be bad form to set MACHINE_KERNEL_PR in the kernel .bb file then May 17 16:03:10 yeah May 17 16:03:22 machine.conf, like the comment says ;) May 17 16:03:50 nice. May 17 16:04:58 Tartarus: heh :) one other question. if kernel.bbclass sets PR = "${MACHINE_KERNEL_PR}" and bitbake.conf does a soft assign, then surely that would indicate that I have a MACHINE_KERNEL_PR set somewhere, or there is a default? May 17 16:06:21 Tartarus: ah never mind, I get it now :) May 17 16:09:13 Tartarus: so effectively PR in a kernel recipe is useless then... though I guess I should set it to the MACHINE_KERNEL_PR value for consistancy? May 17 16:23:23 well, not quite May 17 16:23:34 PR in a kernel recipe is managed by a different variable May 17 16:23:46 since we want to tie multiple recipes to the same PR May 17 16:24:07 for external kernel modules and some other external stuff, for example, with TI boards May 17 16:24:51 So that means instead of managing it in the recipe file itself (where it wouldn't be exposed to other recipes) you manage it in a conf file, where it will be May 17 16:39:39 mickeyl: good morning May 17 16:40:16 hi mickeyl May 17 16:40:19 morning folks May 17 16:43:27 Tartarus: thanks for that explanation, makes much more sense now. May 17 16:50:03 * RP curses proxys and firewalls May 17 16:51:58 hi kergoth_ May 17 16:53:26 RP, that is a huge issue for some .com people using OE ..... May 17 16:57:11 03Koen Kooi  07org.openembedded.dev * r447d858f5e 10openembedded.git/ (conf/checksums.ini recipes/libusb/libusb1_1.0.1.bb): libusb1: update to 1.0.1 May 17 16:57:22 03Koen Kooi  07org.openembedded.dev * r979d795dcd 10openembedded.git/ (2 files in 2 dirs): midori git: bump SRCREV May 17 17:56:20 Crofton|work: Poky has it pretty much sorted, apart from the hg fetcher :/ May 17 17:57:31 The proxy I'm dealing with has hg blocked which is a showstopper but I have a creative solution... May 17 18:01:30 re May 17 18:01:36 hi hrw May 17 18:10:48 Man, running gcc testsuites on target boards is so slow as to take me back to the pre 20GHz desktop days :) May 17 18:11:20 Tartarus: do we have a package for them? I would like to run them on ep93xx May 17 18:12:04 is it packagable really? May 17 18:13:03 I'll email you all the fun details tho May 17 18:16:17 ok May 17 18:22:10 ok, inc May 17 18:22:23 And yes, someone should wiki that up :) May 17 18:32:35 Tartarus: I'd be interested in that too... May 17 18:33:18 * RP dreams of an automated test server May 17 18:33:52 heh, me too :) May 17 18:35:13 RP, inc May 17 18:35:58 Tartarus: thanks May 17 19:05:29 hi, is there any device that has oe support and that could be used as an ogg player? May 17 19:05:37 and that doesn't boot with haret May 17 19:06:21 er, many/most? May 17 19:06:34 You didn't say portable, so.. :) May 17 19:07:54 ah and portable+enough ram(128 would be great) May 17 19:08:12 because my openmoko or my bug device can't be used as ogg player May 17 19:08:23 thanks May 17 19:08:43 I also want to have a device that I can buy May 17 19:08:48 so something easy to find May 17 19:11:21 Gnutoo: a laptop PC would suit you? May 17 19:12:02 lol...but the laptop is to heavy or to big to go in a pocket and doesn't have sufficent autonomy May 17 19:12:16 there were the recent ipaq...I'm looking right now if they are ok May 17 19:19:25 Gnutoo: ah, ok, now is clearer: you need a UMPC or something smaller May 17 19:19:37 Nokia N8x0 ? May 17 19:19:42 yes and not an x86 umpc May 17 19:20:15 N8x0 would be fine if it was free(power management,wifi,sound are not free) May 17 19:20:55 hmmm... I think there is nothing like that with OE support May 17 19:21:27 why you can't use openmoko? May 17 19:21:29 ouch... May 17 19:21:50 I can't use the openmoko because of several issues including: May 17 19:22:13 *capacitor is too low between sound card and audio connector May 17 19:22:28 *micro-sd-card compatibilities problems May 17 19:22:45 GP2X-F200 would be the perfect device May 17 19:22:54 ok I'll look thanks a lot May 17 19:25:47 Gnutoo: all those subsystems are now in linux-omap AFAIK, I keep meaning to try Angstrom on n8x0 May 17 19:25:53 Gnutoo: gp2x is closed as well May 17 19:26:00 ouch... May 17 19:26:08 * XorA|gone has both devices May 17 19:26:12 ok May 17 19:26:46 I think DJWillis was working on an open 2.6 kernel for gp2x, but I guess with the birth of openpandora thats been abandoned May 17 19:27:05 ok May 17 19:27:18 I'll ask some question to #mamona May 17 19:27:38 thanks a lot May 17 19:27:53 oh and sound is crappy on gp2x :-) May 17 19:28:51 ok May 17 19:28:57 XorA|gone: who, what, wooo, yep, I did a lot of GP2X 2.6 work back in the past, the problem is that the changes to the kernel break 99.9% of GP2X apps (all static linked and relying on 2.4 hacks ;-)). It still builds but has not have much love since 2.6.28. May 17 19:29:45 DJWillis: ah cool, you got further than I thought you had May 17 19:29:54 hmm, angstrom on gp2x May 17 19:30:26 XorA|gone: at one point I had just that ;-). NAND and a few other things are fooked in my 2.6 work (well not mine, several people pitched in). May 17 19:31:05 XorA|gone: also got some of Angstrom going on the GP2X Wiz the other day but Gamepark have yet to release the final shipping kernel source :-o so it's a mess. May 17 19:31:48 :-( May 17 19:31:58 gamepark never learn do thet! May 17 19:31:59 they! May 17 19:32:08 XorA|gone: one thing I was/am trying to get off the ground is some work to cleanup the MagicEyes SoC support in the kernel into a proper march (and setup GIT's to track mainline). May 17 19:35:31 hey, is there a python function I can call from a recipe to get the dependencies of a given package? May 17 19:39:23 DJWillis: such a pitty there seems to be no interest in making that SoC some proper mainline support May 17 19:41:18 XorA|gone: there is a lot of common code with the vairous generations (MMSP2, 2+, Pollux etc.) so with the Wiz I guess maybe there will be some more interest to push. May 17 19:41:45 XorA|gone: or we all just swan off to OMAP and SnapDragon ;-) May 17 19:46:25 DJWillis: heh May 17 19:47:41 XorA|gone: I assume you never got a Pandora dev board? May 17 19:47:58 DJWillis: no May 17 19:49:28 XorA|gone: still after one? I'll try and get you one of mine as I am not sure what happened with other boards going out, lost track/gave up. May 17 19:50:06 DJWillis: how long until actually release? May 17 19:52:32 DJWillis: koen sent me a beagle, so I got an omap 3 at moment May 17 19:52:44 DJWillis: busy with an IT contract at moment though May 17 19:53:19 XorA|gone: I have no idea really, I think the software stack is pretty solid, kernel is not in bad shape but everything takes 4 times longer then planned ;-). May 17 19:53:33 DJWillis: thats what happened to OM as well May 17 19:53:39 XorA|gone: oh, back contracting? cool. May 17 19:53:56 DJWillis: only a short job, but it pays more money than the dole May 17 19:54:31 XorA|gone: yep, and the Pandora is a lot less flush then OM. A lot of people who are really pushing it as just hobby devs like me. May 17 19:54:56 DJWillis: I am hoping it takes off, nice next gen linux handheld May 17 19:56:59 XorA|gone: your hoping it takes off ;-). I'll be over the moon when it is out the door, sunk way to much of my life over the last 2 years into it and it's no fun hacking when there are not lots of people to bounce things off. May 17 20:02:18 * XorA|gone shoots tranmission May 17 20:04:37 XorA|gone: did you do any more hacking with Connman and Network Manager 0.7? May 17 20:04:50 DJWillis: connman should just work in Angstrom May 17 20:04:58 I gave up on NM for being a lost cause May 17 20:17:48 XorA|gone: ahhh, yep, I got all the support for NM 0.7.0 going but the GUI is a pig to get sorted :(. May 17 20:18:22 DJWillis: it was such a disgustingly buggy bit of software on my laptop I gave up all hope May 17 20:22:12 XorA|gone: ;-), ever look at the Bluetooth sister app to connman? Something still sat on my TODO. May 17 20:23:01 DJWillis: not yet May 17 20:30:55 gn8 May 17 20:34:39 whats the oe way to run configure ... May 17 20:46:29 03Rolf Leggewie  07org.openembedded.dev * rd3db0654a6 10openembedded.git/conf/bitbake.conf: bitbake.conf: update GENTOO_MIRROR setting. (Closes: #5054) May 17 20:50:21 03Tim 'timtim' Ellis  07org.openembedded.dev * r3edb5ad048 10openembedded.git/recipes/krb/ (files/copyperms.patch krb5_1.6.3.bb): krb5: Force cp to work due to an permissions issue May 17 21:17:25 03Graeme Gregory  07org.openembedded.dev * rb90bc146cd 10openembedded.git/ (4 files in 3 dirs): May 17 21:17:25 transmission_1.61.bb : add new version of transmission make init run May 17 21:17:25 transmission and transmission user. May 17 21:17:25 transmission_1.40.bb : catchup old version with fixes from new May 17 21:17:25 checksums.ini : add transmission 1.61 May 17 21:19:16 03Roman I Khimov  07xora/angstrom-srcpv * r6d64144303 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): (log message trimmed) May 17 21:19:16 (e)glibc-package: fix kernel version passed to qemu May 17 21:19:16 Binary locale generation fails with May 17 21:19:16 FATAL: kernel too old May 17 21:19:16 if (e)glibc is configured for kernels newer than 2.6.16. This comes from May 17 21:19:17 kernel version check in sysdeps/unix/sysv/linux/dl-osinfo.h. We configure May 17 21:19:21 (e)glibc with "--enable-kernel=${OLDEST_KERNEL}", so to pass this check we May 17 21:19:23 03Roman I Khimov  07xora/angstrom-srcpv * r2b198cea9d 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): May 17 21:19:26 (e)glibc-package: enable binary locale generation on x86 and x86_64 May 17 21:19:28 Works well for this targets, so we can add that to BINARY_LOCALE_ARCHES May 17 21:19:30 whitelist. May 17 21:19:32 Acked-by: Tom Rini May 17 21:19:34 03Koen Kooi  07xora/angstrom-srcpv * r979d795dcd 10openembedded.git/ (2 files in 2 dirs): midori git: bump SRCREV May 17 21:19:39 03Graeme Gregory  07xora/angstrom-srcpv * rb90bc146cd 10openembedded.git/ (4 files in 3 dirs): May 17 21:19:42 transmission_1.61.bb : add new version of transmission make init run May 17 21:19:44 transmission and transmission user. May 17 21:19:46 transmission_1.40.bb : catchup old version with fixes from new May 17 21:19:50 checksums.ini : add transmission 1.61 May 17 21:19:52 03Graeme Gregory  07xora/angstrom-srcpv * r7470fc5e17 10openembedded.git/: May 17 21:19:54 Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv May 17 21:19:56 Conflicts: May 17 21:19:58 recipes/gtk-webcore/midori_git.bb May 17 21:20:00 03Tim 'timtim' Ellis  07xora/angstrom-srcpv * r3edb5ad048 10openembedded.git/recipes/krb/ (files/copyperms.patch krb5_1.6.3.bb): krb5: Force cp to work due to an permissions issue May 17 21:20:03 03Rolf Leggewie  07xora/angstrom-srcpv * rd3db0654a6 10openembedded.git/conf/bitbake.conf: bitbake.conf: update GENTOO_MIRROR setting. (Closes: #5054) May 17 21:20:08 03Roman I Khimov  07xora/angstrom-srcpv * r6065fa491c 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): May 17 21:20:15 (e)glibc-package: set LD_LIBRARY_PATH on binary locale generation May 17 21:20:17 Locale generation might fail with SIGSEGV if host libs get messed with target May 17 21:20:19 libs, that might easily happen via /etc/ld.so.cache when building x86(_64) May 17 21:20:23 target on x86(_64) host. So explicitly specify LD_LIBRARY_PATH to prevent that. May 17 21:20:25 Acked-by: Tom Rini May 17 21:20:27 03Graeme Gregory  07xora/angstrom-srcpv * r22ab7e54be 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv May 17 21:20:30 03Koen Kooi  07xora/angstrom-srcpv * r447d858f5e 10openembedded.git/ (conf/checksums.ini recipes/libusb/libusb1_1.0.1.bb): libusb1: update to 1.0.1 May 17 22:16:59 <_Lucretia_> hi, i'm trying to follow the wiki to build anything for beagleboard (qemu), but it fails with the bitbake stuff May 17 22:17:22 <_Lucretia_> i.e. May 17 22:17:30 <_Lucretia_> ERROR: Build of /home/laguest/src/others/beagle/oe/openembedded/recipes/shasum/shasum-native.bb do_compile failed May 17 22:17:30 <_Lucretia_> ERROR: Task 24 (/home/laguest/src/others/beagle/oe/openembedded/recipes/shasum/shasum-native.bb, do_compile) failed May 17 22:18:07 <_Lucretia_> so i changed the branch to a stable and now it just doesn't do anything May 17 22:18:22 <_Lucretia_> a sanity checker error May 17 22:18:48 <_Lucretia_> ahhh May 17 22:34:45 <_Lucretia_> what target builds angstrom for bb? all i get is errors because of shasum May 17 22:38:10 _Lucretia_, try http://www.linuxtogo.org/gowiki/Angstrom May 17 22:39:51 <_Lucretia_> well, the error in the log is: /usr/bin/ld: crtbegin.o: No such file: No such file or directory May 17 22:40:05 <_Lucretia_> that for bitbake task-base May 17 22:43:01 It sounds like you've got something fundamental misconfigured. May 17 22:43:18 So, start from the begining and confirm your local.conf is right May 17 22:44:22 CCACHE issue? May 17 22:44:33 what are you running on? May 17 22:57:07 * * OE Bug 5098 has been created by  May 17 22:57:09 * * Testbug 03 for cdbot2 May 17 22:57:11 * * http://bugs.openembedded.net/show_bug.cgi?id=5098 May 17 22:58:59 <_Lucretia_> debian lenny, i386 May 17 22:59:05 <_Lucretia_> linux not bsd May 17 22:59:06 * * OE Bug 5098 has been RESOLVED (WORKSFORME) by May 17 22:59:08 * * Testbug 03 for cdbot2 May 17 22:59:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5098 May 17 22:59:31 <_Lucretia_> i have just added CCACHE="" line and that does nothing May 17 22:59:43 Laibsch: bug reporting should be operational again. If not, let me know. May 17 22:59:58 cool, thanks May 17 23:00:17 np May 17 23:00:44 was a simple matter of subscribing the bot to the proper ML ;) May 17 23:02:26 if only everything in life was so easy May 17 23:02:29 ;-) May 17 23:02:39 Hope you are doing good! May 17 23:02:46 tell me about it :/ May 17 23:03:04 not too bad, thanks =) May 17 23:06:27 _Lucretia_, pastebin a complete log May 17 23:06:31 ~pastebin May 17 23:06:33 [~pastebin] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste May 17 23:06:45 sorry about the lag, I am in and out of here May 17 23:17:55 <_Lucretia_> Crofton|work: think i might've found the problem... May 17 23:18:08 what is it? May 17 23:22:44 dinner, l8r May 17 23:23:40 <_Lucretia_> compiler problem May 17 23:23:44 <_Lucretia_> sorted May 17 23:29:02 03Rolf Leggewie  07stable/2009 * rc357770a2d 10openembedded.git/conf/bitbake.conf: May 17 23:29:02 bitbake.conf: update GENTOO_MIRROR setting. (Closes: #5054) May 17 23:29:02 (cherry picked from commit d3db0654a6051ad4b9bd67623a2c9e5186b045ef) May 17 23:29:02 Acked-by: Philip Balister May 17 23:29:02 Acked-by: Marcin Juszkiewicz May 18 00:23:07 * RP sees fun for OE on the horizon with recent hal :/ May 18 00:24:06 updates of hal, udev, e2fsprogs and util-linux -> util-linux-ng are needed pretty much together... May 18 01:29:29 03Ottavio Campana  07org.openembedded.dev * r0533f8261c 10openembedded.git/recipes/libmicrohttpd/libmicrohttpd_0.4.1.bb: libmicrohttpd: new recipe May 18 01:29:34 03Rolf Leggewie  07org.openembedded.dev * r1b4f3b70c8 10openembedded.git/recipes/libmicrohttpd/libmicrohttpd_0.4.1.bb: libmicrohttpd: remove unnecessary PN, add AUTHOR and improve DESCRIPTION and SRC_URI May 18 01:29:40 03Rolf Leggewie  07org.openembedded.dev * rf2f3e71e9f 10openembedded.git/ (2 files in 2 dirs): libmicrohttpd: update to 0.4.2 May 18 01:44:02 03Rolf Leggewie  07org.openembedded.dev * rd62d49a285 10openembedded.git/recipes/xmms-embedded/xmms-embedded_20040327.bb: xmms-embedded: fix -dbg packaging **** ENDING LOGGING AT Mon May 18 02:59:57 2009