| 00:26.10 | *** join/#oe mturquette (n=mturquet@adsl-99-181-197-209.dsl.rcsntx.sbcglobal.net) |
| 00:28.07 | *** join/#oe e-ffi (n=cybercom@dslb-088-068-166-210.pools.arcor-ip.net) |
| 00:48.14 | *** join/#oe bluelightning_ (n=blueligh@pdpc/supporter/active/bluelightning) |
| 01:54.17 | *** join/#oe CSMan_ (n=csman@bas3-montreal31-1242531772.dsl.bell.ca) |
| 02:04.27 | *** join/#oe fraxinas (n=quassel@p54AA3E8C.dip.t-dialin.net) |
| 03:01.09 | *** join/#oe BenLauDC (n=benlau@221.125.8.105) |
| 03:09.43 | *** join/#oe mrmoku|a` (n=mrmoku@ppp-93-104-57-48.dynamic.mnet-online.de) |
| 03:30.47 | *** join/#oe Gnutoo (n=gnutoo@host109-10-dynamic.54-79-r.retail.telecomitalia.it) |
| 03:53.31 | *** join/#oe zecke (n=ich@123-192-147-94.dynamic.kbronet.com.tw) |
| 04:03.25 | *** join/#oe hufnus_cicq (n=hufnus_c@69-12-177-67.dsl.static.sonic.net) |
| 04:11.49 | *** join/#oe rkirti (n=rkirti@117.254.19.28) |
| 04:16.56 | *** join/#oe bin1010 (n=mia@rrcs-71-40-238-241.sw.biz.rr.com) |
| 04:53.32 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 05:14.42 | *** join/#oe rkirti_ (n=rkirti@117.254.20.80) |
| 05:25.01 | zecke | wow bitbake trunk badly woes :( |
| 05:25.25 | CIA-35 | 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * r6065fa491c 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): |
| 05:25.25 | CIA-35 | (e)glibc-package: set LD_LIBRARY_PATH on binary locale generation |
| 05:25.25 | CIA-35 | Locale generation might fail with SIGSEGV if host libs get messed with target |
| 05:25.25 | CIA-35 | libs, that might easily happen via /etc/ld.so.cache when building x86(_64) |
| 05:25.25 | CIA-35 | target on x86(_64) host. So explicitly specify LD_LIBRARY_PATH to prevent that. |
| 05:25.29 | CIA-35 | Acked-by: Tom Rini <trini@embeddedalley.com> |
| 05:25.34 | CIA-35 | 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * r2b198cea9d 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): |
| 05:25.34 | CIA-35 | (e)glibc-package: enable binary locale generation on x86 and x86_64 |
| 05:25.36 | CIA-35 | Works well for this targets, so we can add that to BINARY_LOCALE_ARCHES |
| 05:25.38 | CIA-35 | whitelist. |
| 05:25.40 | CIA-35 | Acked-by: Tom Rini <trini@embeddedalley.com> |
| 05:25.44 | CIA-35 | 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * r6d64144303 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): (log message trimmed) |
| 05:25.47 | CIA-35 | (e)glibc-package: fix kernel version passed to qemu |
| 05:25.49 | CIA-35 | Binary locale generation fails with |
| 05:25.51 | CIA-35 | FATAL: kernel too old |
| 05:25.53 | CIA-35 | if (e)glibc is configured for kernels newer than 2.6.16. This comes from |
| 05:25.55 | CIA-35 | kernel version check in sysdeps/unix/sysv/linux/dl-osinfo.h. We configure |
| 05:25.59 | CIA-35 | (e)glibc with "--enable-kernel=${OLDEST_KERNEL}", so to pass this check we |
| 05:31.36 | *** join/#oe pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 05:45.46 | *** join/#oe rkirti_ (n=rkirti@117.254.22.4) |
| 06:05.38 | *** join/#oe zecke (n=ich@123-192-147-94.dynamic.kbronet.com.tw) |
| 06:42.13 | *** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 07:04.44 | *** join/#oe dirk_ (n=virk@d54C3F4A9.access.telenet.be) |
| 07:06.29 | *** join/#oe Sleep_Walker (n=Sleep@193.179.96.131) |
| 07:26.11 | *** join/#oe greentux (n=lemke@BAA3bee.baa.pppool.de) |
| 07:45.56 | *** join/#oe rwhitby` (n=rwhitby@au1.astc-design.com) |
| 08:00.33 | *** join/#oe gremlin[it] (n=gremlin@217.203.166.93) |
| 08:25.37 | RP | ptitjes|party: I had a further look at the gobject stuff and its a world of pain :( |
| 08:33.06 | *** join/#oe dcordes (n=luke@unaffiliated/dcordes) |
| 08:42.58 | *** join/#oe e-ffi (n=cybercom@dslb-088-068-166-210.pools.arcor-ip.net) |
| 08:54.51 | RP | As a warning to anyone, gobject-introspection works by creating a binary against target libs, then running it |
| 08:58.08 | RP | suspects the only way around this will be qemu |
| 09:00.25 | gremlin[it] | RP, hi ... what are u working on ? |
| 09:00.32 | RP | hi gremlin[it] |
| 09:00.50 | RP | gremlin[it]: In a moment of madness, making gobject-introspection work in poky |
| 09:02.32 | gremlin[it] | ahhhh ... i try on my desktop with few success ... |
| 09:03.57 | gremlin[it] | RP, i try in past to use OE with rpm packaging without success ... maybe i'll need your help soon |
| 09:09.52 | RP | gremlin[it]: for which architecture? |
| 09:10.49 | gremlin[it] | RP, at now i'm making test on qemux86 target but i'll like to AVR32 and beagleboard ... |
| 09:12.07 | RP | gremlin[it]: rpm and yum are not very receptive to the idea of cross builds |
| 09:13.13 | gremlin[it] | 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 :( ... |
| 09:16.09 | pb__ | RP: can't you just make it link with the -native libs instead (and build with the native compiler, obviously)? |
| 09:16.26 | pb__ | I think the results of introspection should be independent of the target so it shouldn't matter which system you're running on. |
| 09:18.43 | RP | pb__: There appears to be type size information embedded in the data so I'm wary of that |
| 09:19.07 | RP | pb__: Also, it would mean building lots of things we don't currently have a -native for :/ |
| 09:20.30 | pb__ | ah, that's a nuisance |
| 09:26.13 | *** join/#oe tomimo (n=kurre@xdsl-83-150-88-111.nebulazone.fi) |
| 09:27.31 | RP | hmm, and running this under qemu isn't quite as simple as it sounds |
| 09:29.17 | gremlin[it] | mhh i trouble with keyboard and mouse in qemu ... ... damn |
| 09:30.05 | RP | gremlin[it]: This isn't the qemu system emulator, just the commandline one |
| 09:35.02 | *** join/#oe Laibsch (n=Laibsch@p5B3B1C0F.dip.t-dialin.net) |
| 09:35.08 | Laibsch | good morning |
| 09:40.24 | RP | hi Laibsch |
| 09:41.37 | pb__ | 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. |
| 09:42.04 | pb__ | 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. |
| 09:42.26 | RP | pb__: I'm not 100% certain whether its doing anything nasty with the sizes or not yet |
| 09:42.59 | RP | pb__: Its the idea of requiring -native packages for the whole software stack that scares me :/ |
| 09:43.33 | pb__ | 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. |
| 09:44.18 | pb__ | 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. |
| 09:44.32 | pb__ | obviously that'd lose if the introspector wants to invoke constructors or whatever but I can't think why it would do. |
| 09:45.12 | RP | pb__: It looks like it runs code, I'm nnot sure why |
| 09:45.37 | pb__ | that is a bit weird. can you tell what code? |
| 09:46.09 | RP | pb__: Its linking some kind of xml data dumper around the librbary, then running it |
| 09:46.50 | pb__ | 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. |
| 09:47.11 | pb__ | 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. |
| 09:47.40 | pb__ | it probably does call a pile of stuff from GLib, but obviously we have a native build of that already. |
| 09:48.38 | RP | pb__: taking the example of glib, its trying to load a load of the gio modules |
| 09:49.02 | RP | Instead of the ones in staging, it then finds my /usr/lib/ ones |
| 09:49.34 | RP | 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 |
| 09:50.17 | RP | Linking an x86 scanner around an arm lib doesn't sound like something the linker will like |
| 09:50.21 | pb__ | 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. |
| 09:50.57 | pb__ | 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. |
| 09:51.18 | pb__ | 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. |
| 09:51.39 | RP | pb__: Its a bad testcase but kind of funamental to the package... |
| 09:51.40 | pb__ | 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. |
| 09:52.12 | RP | I already have a -native version which generates the the compiler/scanner and then patches the non-native version to use the native binaries |
| 09:52.29 | pb__ | RP: sure, what I meant is that it might be easier to start debugging it with a simpler library rather than trying glib straightaway. |
| 09:52.43 | pb__ | 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. |
| 09:53.18 | RP | pb__: agreed |
| 09:53.38 | RP | doesn't really have time to take this any futher, I'll just have to disable introspection :/ |
| 09:57.13 | *** join/#oe user1 (n=3MX@62-31-160-229.cable.ubr11.aztw.blueyonder.co.uk) |
| 10:12.49 | pb__ | yah, probably the easiest solution for now |
| 10:12.54 | *** join/#oe Laibsch1 (n=Laibsch@p5B3B175A.dip.t-dialin.net) |
| 10:15.13 | *** join/#oe Laibsch2 (n=Laibsch@p5B3B31B9.dip.t-dialin.net) |
| 10:19.31 | RP | chokes |
| 10:19.39 | RP | this herbal tea is ghastly... |
| 10:20.13 | *** join/#oe kristoffer (n=kristoff@95.209.88.103.bredband.tre.se) |
| 10:23.02 | *** join/#oe mnabil (n=mnabil@196.202.97.147) |
| 10:27.16 | pb__ | heh |
| 10:27.35 | pb__ | RP: are you pregnant? |
| 10:32.47 | *** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 10:33.50 | RP | pb__: Not that I was aware of... |
| 10:34.25 | RP | I was given some and decided I should at least try it. Which was a mistake. |
| 10:34.26 | pb__ | ah, just wondering what made you want to drink herbal tea |
| 10:34.30 | pb__ | heh, fair enough |
| 10:46.51 | *** join/#oe mgwpub (n=mgwpub@193.170.132.135) |
| 10:50.09 | *** join/#oe Eismann (n=foo@247.70.222.87.dynamic.jazztel.es) |
| 10:54.15 | *** join/#oe marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 11:09.52 | *** join/#oe Eismann (n=foo@247.70.222.87.dynamic.jazztel.es) |
| 11:30.05 | *** join/#oe kristoffer (n=kristoff@95.209.88.103.bredband.tre.se) |
| 11:35.16 | *** join/#oe sepultina (n=quassel@zux221-173-049.adsl.green.ch) |
| 11:40.48 | *** join/#oe pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 11:49.37 | Laibsch | Hi |
| 11:49.58 | Laibsch | I'm trying to push a few things to a personal, remote branch, but it fails: http://rafb.net/p/d9nFxm17.html |
| 11:50.17 | Laibsch | What am I doing wrong? "git push oe" usually works when pushing to .dev |
| 12:01.20 | RP | Laibsch: What is the name of the local branch and what is the name of the remote branch you want to push to? |
| 12:01.58 | RP | Laibsch: I usually end up resorting to "git push oe localbranchname:refs/heads/remotebranchname" |
| 12:02.17 | Laibsch | 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 |
| 12:02.41 | RP | So the local branch is master? |
| 12:03.25 | Laibsch | not sure |
| 12:03.35 | Laibsch | It is the currently checked out branch |
| 12:03.57 | Laibsch | But IIRC "git branch" colors the master green for me and it does not in this case |
| 12:04.06 | Laibsch | Still so much to learn about git |
| 12:04.10 | RP | Laibsch: Try git push oe master:refs/heads/laibsch/scim |
| 12:04.19 | Laibsch | thanks, I will |
| 12:05.15 | Laibsch | http://rafb.net/p/N0MxKU64.html looks the same, still no luck |
| 12:05.45 | Laibsch | got it |
| 12:06.01 | Laibsch | git push oe org.openembedded.dev:refs/heads/laibsch/scim |
| 12:06.08 | RP | right :) |
| 12:06.14 | Laibsch | thanks |
| 12:06.24 | RP | I was going to ask what the local branch was called if not master :) |
| 12:06.56 | Laibsch | http://cgit.openembedded.net/cgit.cgi?url=openembedded/log/&h=laibsch/scim |
| 12:07.04 | Laibsch | and it's where it should be |
| 12:07.23 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 12:13.32 | CIA-35 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07laibsch/scim * r8d7669b1fe 10openembedded.git/conf/checksums.ini: checksums.ini: add scim 1.4.6 and 1.4.9 |
| 12:13.33 | CIA-35 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07laibsch/scim * r2717d679f8 10openembedded.git/recipes/scim/ (scim.inc scim_1.4.9.bb): scim: create .inc and add 1.4.6 recipe |
| 12:18.44 | CIA-35 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07laibsch/scim * rcfce543560 10openembedded.git/recipes/scim/scim.inc: scim: replace "sed;mv" with "sed -i" |
| 12:18.45 | CIA-35 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07laibsch/scim * r8187795235 10openembedded.git/recipes/scim/scim_1.4.6.bb: scim: add 1.4.6 recipe |
| 12:21.18 | *** join/#oe jmau (n=jmau@port-92-202-106-123.dynamic.qsc.de) |
| 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/ |
| 12:24.01 | Laibsch | 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 |
| 12:24.13 | Laibsch | scim has thus far not been a part of OE |
| 12:25.55 | Laibsch | uim is failing now, too: http://tinderbox.openembedded.net/packages/556977/ and that one is in OE and used to compile fine, too |
| 12:26.51 | RP | Laibsch: I looked but I don't know off hand. ltdl isn't anything to do with libtool is it? |
| 12:27.09 | Laibsch | no idea |
| 12:27.11 | Laibsch | ;-) |
| 12:27.17 | Laibsch | thanks for looking |
| 12:27.53 | Laibsch | could be a library |
| 12:28.03 | Laibsch | google has libltdl among the first hits |
| 12:28.12 | Laibsch | maybe I'm just missing a compile-time dependency |
| 12:28.37 | Laibsch | but, yes, libtdl seems to be related to libtool |
| 12:28.47 | Laibsch | We had a recent update, didn't we? |
| 12:29.18 | RP | Laibsch: For ltdl, we usually rip out the version in the package and make it use the shared one |
| 12:29.37 | Laibsch | how do you do that? |
| 12:29.43 | Laibsch | Some kind of flag? |
| 12:29.48 | Laibsch | or serious patching? |
| 12:29.57 | RP | Laibsch: Er, usually serious patching :( |
| 12:30.04 | Laibsch | darn |
| 12:30.19 | Laibsch | I looked for patches in debian, but they don't seem to need them |
| 12:30.32 | RP | It might not be needed but its how I usually end up dealing with that problem :/ |
| 12:30.33 | Laibsch | Does OE have a newer libtool than Debian? |
| 12:30.45 | pb__ | yes, libltdl is libtool's dynamic loader library. I think it basically wraps dlopen() in some crazy libtool way. |
| 12:30.46 | RP | Laibsch: out libtool usage is a bit different to debian |
| 12:30.58 | Laibsch | ok |
| 12:30.58 | RP | s/out/our/ |
| 12:31.29 | RP | Laibsch: The "libtool" package should build a libltdl you can link against |
| 12:31.45 | Laibsch | although I doubt I may be able to patch things, how would I approach it? |
| 12:31.50 | Laibsch | some kind of HOWTO online? |
| 12:34.34 | RP | Laibsch: I just downloaded the source and took a look |
| 12:34.37 | pb__ | actually, looking at your logs, I don't think your scim problem is directly libtool related. |
| 12:34.38 | RP | It doesn't look so bad |
| 12:34.53 | Laibsch | glad to hear that |
| 12:34.57 | pb__ | ltdl.cpp isn't a file that libtool ships, it's all written in c. this must be some scim-specific ltdl emulation. |
| 12:35.02 | Laibsch | and thanks for taking a look |
| 12:35.03 | RP | pb__: ltdl.cpp is copied from libtool |
| 12:35.23 | RP | pb__: Its tied to the version of libtool the package is autoconf'd with I suspect |
| 12:35.33 | pb__ | RP: really? I didn't think libtool provided any c++ bits at all |
| 12:35.42 | *** join/#oe jayix (n=Owner@202-89-173-144.static.dsl.amnet.net.au) |
| 12:36.14 | pb__ | 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 |
| 12:36.32 | Laibsch | pb_: is this 1.4.9? |
| 12:36.47 | RP | pb__: You are indeed correct |
| 12:36.50 | Laibsch | These Japanese guys unfortunately have a tendency do reinvent the wheel every time |
| 12:36.51 | pb__ | Laibsch: um, dunno, it's one of the links you posted. just a moment. |
| 12:36.58 | pb__ | yeah, 1.4.9 |
| 12:37.02 | Laibsch | good |
| 12:37.09 | Laibsch | that one is at least very recent |
| 12:37.24 | RP | Laibsch: So you need to fix the compile error, what I said above was wrong |
| 12:37.31 | Laibsch | OK |
| 12:37.37 | Laibsch | I think I'll post to the ml |
| 12:37.55 | pb__ | 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. |
| 12:37.57 | Laibsch | It sounds complicated and I will certainly need quite a bit of help |
| 12:38.01 | RP | I think they took the ltdl.c from libtool and renamed it .cpp |
| 12:38.35 | pb__ | anyway, i think it needs debugging from first principles; I don't think you can trivially pull in a different ltdl from outside. |
| 12:38.36 | RP | You could try seeing how much they butchered it and if you could merge in bits of a more recent ltdl.c |
| 12:39.48 | Laibsch | Is this something that they should be discouraged to continue doing? |
| 12:40.00 | Laibsch | I'd certainly want to educate them where I can |
| 12:40.16 | jayix | hey im having trouble bitbaking angstrom |
| 12:40.22 | jayix | it keeps failing on binutils |
| 12:41.16 | RP | Laibsch: It would depend on why they did it |
| 12:41.31 | Laibsch | OK |
| 12:41.43 | jayix | has anyone possibly come across this before |
| 12:42.25 | Laibsch | jayix: look at tinderbox.openembedded.net |
| 12:42.37 | Laibsch | but I think binutils should generally build fine for most |
| 12:42.52 | Laibsch | 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 |
| 12:43.10 | jayix | thanks |
| 12:44.22 | jayix | where can i find the more in detail log? not the one that the console pumps out |
| 12:45.18 | Laibsch | Easiest way is to use tinderbox |
| 12:45.40 | Laibsch | otherwise the path to the log should also be given on the console |
| 12:45.47 | Laibsch | look among the last few lines |
| 12:46.20 | Laibsch | http://tinderbox.openembedded.net/packages/binutils/ |
| 12:46.24 | Laibsch | looks very good |
| 12:50.10 | jayix | god there is some handy shit for linux |
| 12:50.39 | jayix | almost makes up for things never working the first time |
| 12:50.43 | jayix | thanks |
| 12:50.46 | *** join/#oe codejone (n=codejone@atomos.nxsh.org) |
| 12:51.27 | *** part/#oe codejone (n=codejone@atomos.nxsh.org) |
| 12:52.11 | Laibsch | hehe |
| 13:00.25 | *** join/#oe Gnutoo (n=gnutoo@host109-10-dynamic.54-79-r.retail.telecomitalia.it) |
| 13:09.31 | *** join/#oe greentux (n=lemke@BAA3bee.baa.pppool.de) |
| 13:15.19 | *** join/#oe Spyro (n=ian@benden.mnementh.co.uk) |
| 13:15.54 | *** part/#oe Spyro (n=ian@benden.mnementh.co.uk) |
| 13:17.57 | *** join/#oe Flyser_ (n=Flyser@unaffiliated/flyser) |
| 13:19.33 | *** join/#oe markos_ (n=markos@athedsl-429396.home.otenet.gr) |
| 13:36.50 | *** join/#oe gremlin[it] (n=gremlin@217.203.166.93) |
| 13:43.15 | Laibsch | CoreDump: any news on cdbot2? |
| 13:56.35 | *** join/#oe gerwinin (n=gerwinin@220-136-37-202.dynamic.hinet.net) |
| 14:02.58 | Crofton | arg, I wonder how many addresses I can post to oe-dev at ..... |
| 14:17.34 | *** join/#oe mwester_ (n=mwester@nslu2-linux/mwester) |
| 14:19.52 | pb__ | loads, I expect. |
| 14:20.12 | pb__ | probably openembedded-devel@ every domain that serenity is configured to accept mail for |
| 14:28.07 | Crofton|work | yeah |
| 14:28.22 | Crofton|work | annoying in case we ever move the lists from ltg |
| 14:28.47 | Crofton|work | I suppose I'll see if I can figure out how resolve this |
| 14:30.15 | *** join/#oe rkirti (n=rkirti@117.254.20.7) |
| 14:35.43 | *** join/#oe pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 14:38.07 | *** join/#oe LakeSolon (n=blake@96-42-127-243.dhcp.roch.mn.charter.com) |
| 14:42.34 | *** join/#oe darion76 (n=darion76@92.49.235.1) |
| 14:54.39 | pb__ | 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. |
| 15:01.02 | Crofton|work | pb_, yeah I'll hunt around |
| 15:01.18 | Crofton|work | I think you can also post via the ltg addresses |
| 15:02.53 | pb__ | probably. I've never checked but my guess is that it'll accept anything in exim's local-domains list. |
| 15:07.33 | Crofton|work | lists.oe.org is CNAMED to oe.org |
| 15:07.53 | Crofton|work | without that the list doesn't work |
| 15:08.05 | *** join/#oe bluelightning (n=blueligh@pdpc/supporter/active/bluelightning) |
| 15:14.36 | *** join/#oe drw (n=drw@cpe-76-187-64-213.tx.res.rr.com) |
| 15:20.45 | *** join/#oe sweetlilmre (i=sweetlil@dsl-244-137-108.telkomadsl.co.za) |
| 15:23.03 | sweetlilmre | 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 ?!? |
| 15:23.13 | *** join/#oe bin1010 (n=mia@rrcs-71-40-238-241.sw.biz.rr.com) |
| 15:29.47 | *** join/#oe ArteK (n=Artur@81.15.241.96) |
| 15:52.40 | *** join/#oe timtimred (n=meh@79-75-241-169.dynamic.dsl.as9105.com) |
| 15:54.37 | rkirti | 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 ? |
| 15:55.11 | sweetlilmre | rkirti: thanks I will give that a go now |
| 15:55.50 | sweetlilmre | rkirti: won't that bork the src url tho? |
| 15:58.32 | rkirti | 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.. |
| 15:58.58 | sweetlilmre | rkirti: its fun isn't it :) if not a little frustrating at times! |
| 15:59.01 | Tartarus | looks |
| 15:59.27 | Tartarus | what error do you see? |
| 15:59.48 | Tartarus | just that your output is r0 not r2? |
| 15:59.57 | sweetlilmre | Tartarus: no error, just that if I bump the PR version to say "r1", OE still builds the packages as r0 |
| 16:00.24 | sweetlilmre | Tartarus: which is frustrating... :) |
| 16:00.25 | Tartarus | with current OE, right? |
| 16:00.31 | Tartarus | PR for kernel is special |
| 16:00.40 | Tartarus | kernel.bbclass now does: |
| 16:00.46 | Tartarus | # A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force |
| 16:00.46 | Tartarus | # rebuilds for kernel and external modules |
| 16:00.46 | Tartarus | PR = "${MACHINE_KERNEL_PR}" |
| 16:01.11 | Tartarus | and bitbake.conf does a soft (?=) assignment to r0 |
| 16:01.16 | sweetlilmre | Tartarus: shouldn't that be: PR ?= "${MACHINE_KERNEL_PR}" |
| 16:01.26 | sweetlilmre | seems backwards |
| 16:01.30 | Tartarus | sweetlilmre, no, it's intended to be special like this |
| 16:01.45 | Tartarus | So that external modules, and other stuff that depends on the kernel will be bumped |
| 16:02.07 | sweetlilmre | Tartarus: so I should set MACHINE_KERNEL_PR in my machine conf then? |
| 16:02.21 | Tartarus | if you need to go from r0 to r1, yes |
| 16:03.00 | sweetlilmre | 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 |
| 16:03.10 | Tartarus | yeah |
| 16:03.22 | Tartarus | machine.conf, like the comment says ;) |
| 16:03.50 | rkirti | nice. |
| 16:04.58 | sweetlilmre | 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? |
| 16:06.21 | sweetlilmre | Tartarus: ah never mind, I get it now :) |
| 16:09.13 | sweetlilmre | 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? |
| 16:23.23 | Tartarus | well, not quite |
| 16:23.34 | Tartarus | PR in a kernel recipe is managed by a different variable |
| 16:23.46 | Tartarus | since we want to tie multiple recipes to the same PR |
| 16:24.07 | Tartarus | for external kernel modules and some other external stuff, for example, with TI boards |
| 16:24.51 | Tartarus | 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 |
| 16:28.10 | *** part/#oe gerwinin (n=gerwinin@220-136-37-202.dynamic.hinet.net) |
| 16:39.40 | pb__ | mickeyl: good morning |
| 16:40.16 | RP | hi mickeyl |
| 16:40.20 | mickeyl | morning folks |
| 16:43.27 | sweetlilmre | Tartarus: thanks for that explanation, makes much more sense now. |
| 16:46.34 | *** join/#oe aloisiojr (n=aloisio@189.81.156.193) |
| 16:48.00 | *** join/#oe Flyser (n=Flyser@unaffiliated/flyser) |
| 16:49.03 | *** join/#oe kergoth_ (n=kergoth@ip98-167-215-86.ph.ph.cox.net) |
| 16:50.03 | RP | curses proxys and firewalls |
| 16:50.39 | *** join/#oe valhalla (n=valhalla@81-174-25-145.dynamic.ngi.it) |
| 16:51.58 | pb__ | hi kergoth_ |
| 16:53.02 | *** part/#oe ArteK (n=Artur@81.15.241.96) |
| 16:53.26 | Crofton|work | RP, that is a huge issue for some .com people using OE ..... |
| 16:57.11 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r447d858f5e 10openembedded.git/ (conf/checksums.ini recipes/libusb/libusb1_1.0.1.bb): libusb1: update to 1.0.1 |
| 16:57.22 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r979d795dcd 10openembedded.git/ (2 files in 2 dirs): midori git: bump SRCREV |
| 17:06.54 | *** join/#oe pvanhoof (n=pvanhoof@d54C0C0BA.access.telenet.be) |
| 17:51.32 | *** join/#oe fraxinas (n=quassel@p54AA44B7.dip.t-dialin.net) |
| 17:56.20 | RP | Crofton|work: Poky has it pretty much sorted, apart from the hg fetcher :/ |
| 17:57.30 | RP | The proxy I'm dealing with has hg blocked which is a showstopper but I have a creative solution... |
| 18:00.05 | *** join/#oe dth1 (n=dth@p4FDEFEC2.dip.t-dialin.net) |
| 18:01.58 | hrw | re |
| 18:01.58 | RP | hi hrw |
| 18:10.48 | Tartarus | Man, running gcc testsuites on target boards is so slow as to take me back to the pre 20GHz desktop days :) |
| 18:11.20 | hrw | Tartarus: do we have a package for them? I would like to run them on ep93xx |
| 18:12.04 | Tartarus | is it packagable really? |
| 18:13.03 | Tartarus | I'll email you all the fun details tho |
| 18:15.42 | *** join/#oe koobe (n=koobe@83.150.95.26) |
| 18:16.18 | hrw | ok |
| 18:16.36 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 18:17.02 | *** join/#oe ArteK (n=Artur@81.15.241.96) |
| 18:22.10 | Tartarus | ok, inc |
| 18:22.23 | Tartarus | And yes, someone should wiki that up :) |
| 18:32.35 | RP | Tartarus: I'd be interested in that too... |
| 18:33.18 | RP | dreams of an automated test server |
| 18:33.53 | Tartarus | heh, me too :) |
| 18:35.13 | Tartarus | RP, inc |
| 18:35.58 | RP | Tartarus: thanks |
| 18:42.21 | *** join/#oe pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 18:47.26 | *** join/#oe mnabil (n=mnabil@82.201.174.70) |
| 19:05.29 | Gnutoo | hi, is there any device that has oe support and that could be used as an ogg player? |
| 19:05.37 | Gnutoo | and that doesn't boot with haret |
| 19:06.22 | Tartarus | er, many/most? |
| 19:06.34 | Tartarus | You didn't say portable, so.. :) |
| 19:07.55 | Gnutoo | ah and portable+enough ram(128 would be great) |
| 19:08.12 | Gnutoo | because my openmoko or my bug device can't be used as ogg player |
| 19:08.23 | Gnutoo | thanks |
| 19:08.43 | Gnutoo | I also want to have a device that I can buy |
| 19:08.48 | Gnutoo | so something easy to find |
| 19:11.22 | mckoan | Gnutoo: a laptop PC would suit you? |
| 19:12.02 | Gnutoo | lol...but the laptop is to heavy or to big to go in a pocket and doesn't have sufficent autonomy |
| 19:12.17 | Gnutoo | there were the recent ipaq...I'm looking right now if they are ok |
| 19:14.12 | *** join/#oe mems (n=rob@87-194-128-93.bethere.co.uk) |
| 19:19.25 | mckoan | Gnutoo: ah, ok, now is clearer: you need a UMPC or something smaller |
| 19:19.37 | mckoan | Nokia N8x0 ? |
| 19:19.42 | Gnutoo | yes and not an x86 umpc |
| 19:20.15 | Gnutoo | N8x0 would be fine if it was free(power management,wifi,sound are not free) |
| 19:20.55 | mckoan | hmmm... I think there is nothing like that with OE support |
| 19:21.27 | mckoan | why you can't use openmoko? |
| 19:21.29 | Gnutoo | ouch... |
| 19:21.50 | Gnutoo | I can't use the openmoko because of several issues including: |
| 19:22.13 | Gnutoo | *capacitor is too low between sound card and audio connector |
| 19:22.28 | Gnutoo | *micro-sd-card compatibilities problems |
| 19:22.45 | mckoan | GP2X-F200 would be the perfect device |
| 19:22.54 | Gnutoo | ok I'll look thanks a lot |
| 19:25.47 | XorA|gone | Gnutoo: all those subsystems are now in linux-omap AFAIK, I keep meaning to try Angstrom on n8x0 |
| 19:25.53 | XorA|gone | Gnutoo: gp2x is closed as well |
| 19:26.00 | Gnutoo | ouch... |
| 19:26.09 | XorA|gone | has both devices |
| 19:26.12 | Gnutoo | ok |
| 19:26.46 | XorA|gone | I think DJWillis was working on an open 2.6 kernel for gp2x, but I guess with the birth of openpandora thats been abandoned |
| 19:27.05 | Gnutoo | ok |
| 19:27.18 | Gnutoo | I'll ask some question to #mamona |
| 19:27.38 | Gnutoo | thanks a lot |
| 19:27.53 | XorA|gone | oh and sound is crappy on gp2x :-) |
| 19:28.51 | Gnutoo | ok |
| 19:28.57 | DJWillis | 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. |
| 19:29.45 | XorA|gone | DJWillis: ah cool, you got further than I thought you had |
| 19:29.55 | XorA|gone | hmm, angstrom on gp2x |
| 19:30.26 | DJWillis | 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). |
| 19:31.06 | DJWillis | 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. |
| 19:31.49 | XorA|gone | :-( |
| 19:31.58 | XorA|gone | gamepark never learn do thet! |
| 19:31.59 | XorA|gone | they! |
| 19:32.08 | DJWillis | 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). |
| 19:35.31 | mems | hey, is there a python function I can call from a recipe to get the dependencies of a given package? |
| 19:36.57 | *** join/#oe user1 (n=3MX@cpc2-stkp6-0-0-cust377.manc.cable.ntl.com) |
| 19:36.59 | *** join/#oe user2 (n=3MX@cpc2-stkp6-0-0-cust377.manc.cable.ntl.com) |
| 19:39.23 | XorA|gone | DJWillis: such a pitty there seems to be no interest in making that SoC some proper mainline support |
| 19:41.18 | DJWillis | 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. |
| 19:41.45 | DJWillis | XorA|gone: or we all just swan off to OMAP and SnapDragon ;-) |
| 19:46.00 | *** join/#oe valhalla (n=valhalla@81-174-25-145.dynamic.ngi.it) |
| 19:46.26 | XorA|gone | DJWillis: heh |
| 19:47.41 | DJWillis | XorA|gone: I assume you never got a Pandora dev board? |
| 19:47.59 | XorA|gone | DJWillis: no |
| 19:49.34 | DJWillis | 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. |
| 19:50.07 | XorA|gone | DJWillis: how long until actually release? |
| 19:52.32 | XorA|gone | DJWillis: koen sent me a beagle, so I got an omap 3 at moment |
| 19:52.44 | XorA|gone | DJWillis: busy with an IT contract at moment though |
| 19:53.19 | DJWillis | 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 ;-). |
| 19:53.33 | XorA|gone | DJWillis: thats what happened to OM as well |
| 19:53.39 | DJWillis | XorA|gone: oh, back contracting? cool. |
| 19:53.56 | XorA|gone | DJWillis: only a short job, but it pays more money than the dole |
| 19:54.31 | DJWillis | 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. |
| 19:54.56 | XorA|gone | DJWillis: I am hoping it takes off, nice next gen linux handheld |
| 19:56.59 | DJWillis | 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. |
| 20:02.18 | XorA|gone | shoots tranmission |
| 20:04.37 | DJWillis | XorA|gone: did you do any more hacking with Connman and Network Manager 0.7? |
| 20:04.51 | XorA|gone | DJWillis: connman should just work in Angstrom |
| 20:04.58 | XorA|gone | I gave up on NM for being a lost cause |
| 20:12.30 | *** part/#oe ArteK (n=Artur@81.15.241.96) |
| 20:17.48 | DJWillis | XorA|gone: ahhh, yep, I got all the support for NM 0.7.0 going but the GUI is a pig to get sorted :(. |
| 20:18.23 | XorA|gone | DJWillis: it was such a disgustingly buggy bit of software on my laptop I gave up all hope |
| 20:22.12 | DJWillis | XorA|gone: ;-), ever look at the Bluetooth sister app to connman? Something still sat on my TODO. |
| 20:23.01 | XorA|gone | DJWillis: not yet |
| 20:30.55 | mckoan | gn8 |
| 20:34.39 | Crofton|work | whats the oe way to run configure ... |
| 20:44.33 | *** join/#oe Flyser (n=Flyser@unaffiliated/flyser) |
| 20:46.28 | CIA-35 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * rd3db0654a6 10openembedded.git/conf/bitbake.conf: bitbake.conf: update GENTOO_MIRROR setting. (Closes: #5054) |
| 20:47.41 | *** join/#oe dth (n=dth@p4FDEFEC2.dip.t-dialin.net) |
| 20:50.21 | CIA-35 | 03Tim 'timtim' Ellis <tim.ellis@foonas.org> 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 |
| 20:55.05 | *** join/#oe aloisiojr (n=aloisio@189.81.156.193) |
| 21:17.25 | CIA-35 | 03Graeme Gregory <dp@xora.org.uk> 07org.openembedded.dev * rb90bc146cd 10openembedded.git/ (4 files in 3 dirs): |
| 21:17.25 | CIA-35 | transmission_1.61.bb : add new version of transmission make init run |
| 21:17.25 | CIA-35 | transmission and transmission user. |
| 21:17.25 | CIA-35 | transmission_1.40.bb : catchup old version with fixes from new |
| 21:17.25 | CIA-35 | checksums.ini : add transmission 1.61 |
| 21:19.15 | CIA-35 | 03Roman I Khimov <khimov@altell.ru> 07xora/angstrom-srcpv * r6d64144303 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): (log message trimmed) |
| 21:19.16 | CIA-35 | (e)glibc-package: fix kernel version passed to qemu |
| 21:19.16 | CIA-35 | Binary locale generation fails with |
| 21:19.16 | CIA-35 | FATAL: kernel too old |
| 21:19.16 | CIA-35 | if (e)glibc is configured for kernels newer than 2.6.16. This comes from |
| 21:19.17 | CIA-35 | kernel version check in sysdeps/unix/sysv/linux/dl-osinfo.h. We configure |
| 21:19.21 | CIA-35 | (e)glibc with "--enable-kernel=${OLDEST_KERNEL}", so to pass this check we |
| 21:19.23 | CIA-35 | 03Roman I Khimov <khimov@altell.ru> 07xora/angstrom-srcpv * r2b198cea9d 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): |
| 21:19.26 | CIA-35 | (e)glibc-package: enable binary locale generation on x86 and x86_64 |
| 21:19.28 | CIA-35 | Works well for this targets, so we can add that to BINARY_LOCALE_ARCHES |
| 21:19.30 | CIA-35 | whitelist. |
| 21:19.32 | CIA-35 | Acked-by: Tom Rini <trini@embeddedalley.com> |
| 21:19.34 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07xora/angstrom-srcpv * r979d795dcd 10openembedded.git/ (2 files in 2 dirs): midori git: bump SRCREV |
| 21:19.39 | CIA-35 | 03Graeme Gregory <dp@xora.org.uk> 07xora/angstrom-srcpv * rb90bc146cd 10openembedded.git/ (4 files in 3 dirs): |
| 21:19.42 | CIA-35 | transmission_1.61.bb : add new version of transmission make init run |
| 21:19.44 | CIA-35 | transmission and transmission user. |
| 21:19.46 | CIA-35 | transmission_1.40.bb : catchup old version with fixes from new |
| 21:19.50 | CIA-35 | checksums.ini : add transmission 1.61 |
| 21:19.52 | CIA-35 | 03Graeme Gregory <dp@xora.org.uk> 07xora/angstrom-srcpv * r7470fc5e17 10openembedded.git/: |
| 21:19.54 | CIA-35 | Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv |
| 21:19.56 | CIA-35 | Conflicts: |
| 21:19.58 | CIA-35 | recipes/gtk-webcore/midori_git.bb |
| 21:20.00 | CIA-35 | 03Tim 'timtim' Ellis <tim.ellis@foonas.org> 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 |
| 21:20.03 | CIA-35 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07xora/angstrom-srcpv * rd3db0654a6 10openembedded.git/conf/bitbake.conf: bitbake.conf: update GENTOO_MIRROR setting. (Closes: #5054) |
| 21:20.08 | CIA-35 | 03Roman I Khimov <khimov@altell.ru> 07xora/angstrom-srcpv * r6065fa491c 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): |
| 21:20.15 | CIA-35 | (e)glibc-package: set LD_LIBRARY_PATH on binary locale generation |
| 21:20.17 | CIA-35 | Locale generation might fail with SIGSEGV if host libs get messed with target |
| 21:20.19 | CIA-35 | libs, that might easily happen via /etc/ld.so.cache when building x86(_64) |
| 21:20.23 | CIA-35 | target on x86(_64) host. So explicitly specify LD_LIBRARY_PATH to prevent that. |
| 21:20.25 | CIA-35 | Acked-by: Tom Rini <trini@embeddedalley.com> |
| 21:20.27 | CIA-35 | 03Graeme Gregory <dp@xora.org.uk> 07xora/angstrom-srcpv * r22ab7e54be 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv |
| 21:20.30 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07xora/angstrom-srcpv * r447d858f5e 10openembedded.git/ (conf/checksums.ini recipes/libusb/libusb1_1.0.1.bb): libusb1: update to 1.0.1 |
| 21:21.21 | *** part/#oe mems (n=rob@87-194-128-93.bethere.co.uk) |
| 21:27.34 | *** join/#oe Soopaman (n=Soopaman@67.204.25.132) |
| 21:45.13 | *** join/#oe Cwiiis (n=cwiiis@82-43-46-194.cable.ubr02.croy.blueyonder.co.uk) |
| 22:06.48 | *** join/#oe koobe (n=koobe@83.150.95.26) |
| 22:16.17 | *** join/#oe _Lucretia_ (n=Lucretia@5ac95bf2.bb.sky.com) |
| 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 |
| 22:17.22 | _Lucretia_ | i.e. |
| 22:17.30 | _Lucretia_ | ERROR: Build of /home/laguest/src/others/beagle/oe/openembedded/recipes/shasum/shasum-native.bb do_compile failed |
| 22:17.30 | _Lucretia_ | ERROR: Task 24 (/home/laguest/src/others/beagle/oe/openembedded/recipes/shasum/shasum-native.bb, do_compile) failed |
| 22:18.07 | _Lucretia_ | so i changed the branch to a stable and now it just doesn't do anything |
| 22:18.22 | _Lucretia_ | a sanity checker error |
| 22:18.48 | _Lucretia_ | ahhh |
| 22:21.32 | *** join/#oe jconnolly (n=jconnoll@ool-18b96adf.dyn.optonline.net) |
| 22:25.46 | *** join/#oe marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 22:28.52 | *** join/#oe HellDragon (i=jd@Wikipedia/HellDragon) |
| 22:34.45 | _Lucretia_ | what target builds angstrom for bb? all i get is errors because of shasum |
| 22:38.10 | Tartarus | _Lucretia_, try http://www.linuxtogo.org/gowiki/Angstrom |
| 22:39.51 | _Lucretia_ | well, the error in the log is: /usr/bin/ld: crtbegin.o: No such file: No such file or directory |
| 22:40.05 | _Lucretia_ | that for bitbake task-base |
| 22:43.01 | Tartarus | It sounds like you've got something fundamental misconfigured. |
| 22:43.18 | Tartarus | So, start from the begining and confirm your local.conf is right |
| 22:44.22 | Crofton|work | CCACHE issue? |
| 22:44.33 | Crofton|work | what are you running on? |
| 22:57.06 | cdbot2 | * * OE Bug 5098 has been created by <CoreDump> |
| 22:57.08 | cdbot2 | * * Testbug 03 for cdbot2 |
| 22:57.10 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=5098 |
| 22:58.59 | _Lucretia_ | debian lenny, i386 |
| 22:59.05 | _Lucretia_ | linux not bsd |
| 22:59.06 | cdbot2 | * * OE Bug 5098 has been RESOLVED (WORKSFORME) by <CoreDump> |
| 22:59.08 | cdbot2 | * * Testbug 03 for cdbot2 |
| 22:59.10 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=5098 |
| 22:59.31 | _Lucretia_ | i have just added CCACHE="" line and that does nothing |
| 22:59.43 | CoreDump | Laibsch: bug reporting should be operational again. If not, let me know. |
| 22:59.58 | Laibsch | cool, thanks |
| 23:00.17 | CoreDump | np |
| 23:00.45 | CoreDump | was a simple matter of subscribing the bot to the proper ML ;) |
| 23:02.19 | *** join/#oe jayiz` (n=Owner@202-89-173-144.static.dsl.amnet.net.au) |
| 23:02.26 | Laibsch | if only everything in life was so easy |
| 23:02.29 | Laibsch | ;-) |
| 23:02.39 | Laibsch | Hope you are doing good! |
| 23:02.45 | CoreDump | tell me about it :/ |
| 23:03.04 | CoreDump | not too bad, thanks =) |
| 23:06.27 | Crofton|work | _Lucretia_, pastebin a complete log |
| 23:06.32 | Crofton|work | ~pastebin |
| 23:06.33 | ibot | [~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 |
| 23:06.45 | Crofton|work | sorry about the lag, I am in and out of here |
| 23:07.50 | *** join/#oe hbo22 (n=chatzill@132.181.51.98) |
| 23:17.55 | _Lucretia_ | Crofton|work: think i might've found the problem... |
| 23:18.08 | Crofton|work | what is it? |
| 23:22.44 | Crofton|work | dinner, l8r |
| 23:23.40 | _Lucretia_ | compiler problem |
| 23:23.44 | _Lucretia_ | sorted |
| 23:29.02 | CIA-35 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07stable/2009 * rc357770a2d 10openembedded.git/conf/bitbake.conf: |
| 23:29.02 | CIA-35 | bitbake.conf: update GENTOO_MIRROR setting. (Closes: #5054) |
| 23:29.02 | CIA-35 | (cherry picked from commit d3db0654a6051ad4b9bd67623a2c9e5186b045ef) |
| 23:29.02 | CIA-35 | Acked-by: Philip Balister <philip@balister.org> |
| 23:29.02 | CIA-35 | Acked-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |