**** BEGIN LOGGING AT Sat Feb 11 10:59:56 2006 Feb 11 12:43:24 I'm trying to use the native gcc that is built in oe for gpe on familiar. Feb 11 12:43:51 It seems to try to find libc.so.6 in /usr/lib rather than /lib. Feb 11 12:44:25 Am I in the right irc channel? Feb 11 12:44:37 Is this a bug in the metadata for this package? Feb 11 12:44:55 Anyone know how to fix it? Feb 11 12:47:25 If I symlink /lib/libc6.so.6 to /usr/lib/, then it'll try to find /usr/usr/lib/libc_nonshared.a Feb 11 12:48:02 It seems to believe "/usr/bin/../../usr" is "/". Feb 11 12:48:26 That might be a bug, but it's hard to say from those details. Can you tell us exactly what the behaviour is that you're seeing? Feb 11 12:49:39 pb_, if I run "gcc test.c" (a trivial hello world program), then it'll complain that it can't find libc.so.6. Feb 11 12:50:33 I can ssh in and copy the exact error message if you want it, but that'll take a sec. Feb 11 12:51:55 yes, please Feb 11 12:57:32 pb_, http://pastebin.com/549689 Feb 11 12:58:47 what does /usr/lib/libc.so look like? Feb 11 12:59:40 GOUTPUT_FORMAT(elf32-littlearm) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) ) Feb 11 12:59:43 hi all Feb 11 12:59:55 s/GOUTPUT/OUTPUT/ Feb 11 12:59:55 niklash meant: OUTPUT_FORMAT(elf32-littlearm) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) ) Feb 11 13:02:13 if "a" is a int16_t, is "a - (a & 0xfff8)" equal to "a & 7" for any value of "a"? Feb 11 13:02:46 Damn. I meant to try "mv /usr/lib/libc.so /lib", but typed libc.so.6. Guess I'll need to reflash now... Feb 11 13:07:37 That all looks OK. It sounds like the linker isn't behaving in quite the way that glibc wants. Feb 11 13:08:32 hi Feb 11 13:08:47 The "can't find /lib/libc.so.6 in /usr/bin/../../usr" will make it look for /lib in /usr, which yields /usr/lib when we wan't /lib. Feb 11 13:09:11 What I don't know is where /usr/bin/../../usr comes from. Feb 11 13:09:43 At least that's my guess from looking at the output. Feb 11 13:10:42 any got a fixed gaim.bb? Feb 11 13:10:59 gaim_cvs Feb 11 13:15:49 hi Feb 11 13:19:26 hi zecke Feb 11 13:19:54 niklash: yeah. I guess that path must be hard-wired into ld. Feb 11 14:05:43 hi Feb 11 14:07:24 03rwhitby 07org.oe.dev * r20f5c236... 10/packages/ (13 files in 3 dirs): ixp4xx-kernel: Added initial ds101 patchset from NAiL Feb 11 14:07:28 03rwhitby 07org.oe.dev * r494f7afe... 10/packages/ (13 files in 3 dirs): disapproval of revision '20f5c236b9ebdf5e2fc0e5acea55f39e77588bb8' Feb 11 14:07:33 03rwhitby 07org.oe.dev * rca7d3609... 10/packages/linux/ixp4xx-kernel/2.6.16/80-nas100d-fix-i2c.patch: ixp4xx-kernel: Fixed i2c on nas100d (thanks to dwery) Feb 11 14:07:37 03rwhitby 07org.oe.dev * rc07516fb... 10/packages/linux/ixp4xx-kernel_2.6.16-rc2.bb: ixp4xx-kernel: Fixed i2c on nas100d (thanks to dwery) Feb 11 14:07:41 03rwhitby 07org.oe.dev * rd75a82f1... 10/packages/linux/ixp4xx-kernel_2.6.16-rc2.bb: ixp4xx-kernel: Added 94-loft-setup Feb 11 14:07:45 03rwhitby 07org.oe.dev * rfe98d1f2... 10/packages/linux/ (9 files in 2 dirs): ixp4xx-kernel: Added 94-loft-setup, fixed 94-nas100d-setup (dwery), added initial ds101 patchset (NAiL) Feb 11 14:07:49 03rwhitby 07org.oe.dev * r0a0aa499... 10/packages/linux/ixp4xx-kernel.inc: ixp4xx-kernel: Added support for building ds101 kernels. Feb 11 14:07:53 03rwhitby 07org.oe.dev * r8375c2d1... 10/packages/linux/ixp4xx-kernel/2.6.16/97-ds101-includes.patch: ixp4xx-kernel: Fixed path in 97-ds101-includes.patch Feb 11 14:07:57 03rwhitby 07org.oe.dev * r09d118b6... 10/packages/linux/ixp4xx-kernel/2.6.16/94-nas100d-setup.patch: ixp4xx-kernel: Updated 94-nas100d-setup.patch from dwery Feb 11 14:10:12 2.6.16 ?!?!?!?! Feb 11 14:10:45 -rc2 Feb 11 14:10:47 rwhitby: consider 2.6.15+2.6.16-rc2 as PV - less problem with upgrade to 2.6.16 final Feb 11 14:11:06 hrw: good idea Feb 11 14:11:32 rwhitby: we use it in OZ kernels Feb 11 14:11:34 The OZ kernels had the same issue Feb 11 14:11:40 But I wonder whether the logic in ixp4xx-kernel which patches the kernel correctly will handle that ... Feb 11 14:11:52 ixp4xx-kernel.inc that is Feb 11 14:11:53 ~lart ecore Feb 11 14:11:53 * ibot breaks out the Hoover and sucks up ecore Feb 11 14:12:44 ~hail koen for split-feed script Feb 11 14:12:46 * ibot bows down to koen for split-feed script and chants, "I'M NOT WORTHY!!" Feb 11 14:13:21 gcc HEAD does not compile in current OE Feb 11 14:13:22 :( Feb 11 14:13:33 | checking for the %z format string in strftime()... configure: error: cannot run test program while cross compiling Feb 11 14:13:39 now why would it go and do that Feb 11 14:14:14 hrw: do you know enough python to help me work out how to split the PV into the stuff before the + and the stuff after? Feb 11 14:15:08 rwhitby: python is like german to me - know few words Feb 11 14:15:17 same here Feb 11 14:15:36 afternoon Feb 11 14:15:43 i mis-spoke Feb 11 14:15:51 s/gcc/gaim/ Feb 11 14:16:03 hm. need to use hh.org bugzilla again ;( Feb 11 14:16:22 the gaim HEAD is package which does not compile, due to %z format error in do_configure phase Feb 11 14:17:35 conftest.c:67: warning: conflicting types for built-in function 'strftime' Feb 11 14:17:41 when it is being built with gcc4 Feb 11 14:17:42 hm Feb 11 14:18:06 how do i capture the output of the c source it is compiling? Feb 11 14:18:14 i mean, to get the c source Feb 11 14:18:16 so i can look at it Feb 11 14:18:26 shadows: config.log and configure? Feb 11 14:18:35 so, go through configure hrm Feb 11 14:24:16 rather not-convenient Feb 11 14:33:38 ~curse handhelds.org bugzilla admins for too much entries in product list Feb 11 14:33:39 May you be reincarnated as a Windows XP administrator, handhelds.org bugzilla admins for too much entries in product list ! Feb 11 14:46:44 cu Feb 11 15:04:59 ~lart autotools borking gaim Feb 11 15:04:59 * ibot takes a rusty axe and swings it violently, taking autotools borking gaim's head off Feb 11 15:05:59 * CoreDump|home curses Feb 11 15:20:55 03pH5 07org.oe.dev * ra2365934... 10/ (3 files in 3 dirs): Feb 11 15:20:55 gaim_cvs: build fix Feb 11 15:20:55 - drop desktop-name-cvs.patch, doesn't apply anymore Feb 11 15:20:55 - work around the strftime %z support test Feb 11 15:42:51 super Feb 11 15:43:00 i was going to submit a bug report about the strftime %z test Feb 11 15:43:04 i guess he beat me to it Feb 11 15:53:49 okay the next failure with gcc4 is osb-jscore Feb 11 15:54:02 it's the "qualification" bug Feb 11 15:54:04 already documented Feb 11 15:54:20 i cannot find the patch mentioned in http://www.handhelds.org/hypermail/oe/40/4041.html Feb 11 15:54:24 does anyone else have it? Feb 11 17:59:52 * france is away: Away Feb 11 18:11:40 03hrw 07org.oe.oz354fam083 * r059ff7db... 10/packages/sharp-binary-only/sharp-sdmmc-support.bb: sharp-sdmmc-support: unbreak it if kernel is not yet built - close #679 Feb 11 18:11:45 03hrw 07org.oe.dev * rab5c1cdb... 10/packages/sharp-binary-only/sharp-sdmmc-support.bb: Feb 11 18:11:45 sharp-sdmmc-support: unbreak it if kernel is not yet built - close #679 Feb 11 18:11:45 taken from .oz354fam083 Feb 11 19:40:15 did anyone play with package_ipk.bbclass recently? Feb 11 19:41:01 * Zero_Chaos points at JustinP Feb 11 19:41:33 you're kidding right Feb 11 19:41:35 think I remember him saying he fixed something Feb 11 19:41:40 hehe Feb 11 19:41:50 probably for e-image-core Feb 11 19:42:32 CoreDump|home: don't hold me too it though, I remember someone saying they messed with it, I am only pretty sure it was JustinP Feb 11 19:42:32 well, "something" broke ecore-x11, and I'm almost sure it's coming from that bbclass Feb 11 19:42:47 Zero_Chaos: thanks =) Feb 11 19:42:57 * Zero_Chaos hides from JustinP Feb 11 20:02:51 Zero_Chaos: YES Feb 11 20:02:56 got the bug Feb 11 20:03:11 CoreDump|home: sweet Feb 11 20:10:45 that was a nasty one :\ Feb 11 20:37:34 re Feb 11 20:40:01 mreimer: man, i try to build boost, but it poors everything on the swap and it's killing the hard driver, i don't know what to do =/ Feb 11 20:45:59 I made libxine compile with GCC 4, what do I win? (And where do I send the patch?) Feb 11 21:15:55 koen|away: where is out wish list for CELF? Feb 11 21:18:27 DataBeaver: bugs.treke.net attach it Feb 11 21:18:35 DataBeaver: and send it upstream to the xine people... Feb 11 21:34:22 so it's not possible to RDEPEND on a auto-munged lib* package Feb 11 21:34:37 grrrr Feb 11 21:35:12 JustinP: well if you link to it Feb 11 21:35:19 03justinp 07org.oe.dev * r285917d8... 10/classes/efl.bbclass: efl.bbclass: switch to from to work around bitbake problems, switch from += as package.bbclass breaks on it Feb 11 21:35:21 JustinP: it will automatically on a lib* munged package Feb 11 21:35:24 03justinp 07org.oe.dev * rde2e4aa6... 10/packages/e17/ (2 files in 2 dirs): e17-gpe-menu-convert: remove , add PATH_TO_PIXMAPS, switch tabs to spaces, switch RDEPENDS back to libedje-dev, remove postinst for now Feb 11 21:35:28 03justinp 07org.oe.dev * r03c981e4... 10/packages/efl/ (edb_1.0.5.005.bb edje_0.5.0.023.bb embryo_0.9.1.023.bb): edb, embryo, edje: remove -utils packages as package.bbclass can't handle it Feb 11 21:35:31 zecke: nope Feb 11 21:35:32 03justinp 07org.oe.dev * r48f276ac... 10/packages/efl/evas-x11_0.9.9.023.bb: evas-x11: --enable-buffer, edje_cc needs it Feb 11 21:35:37 03justinp 07org.oe.dev * r883c5828... 10/packages/efl/evas.inc: evas.inc: remove unneeded do_configure Feb 11 21:35:41 03justinp 07org.oe.dev * r967b737b... 10/packages/meta/task-e-x11.bb: task-e-x11-core: add new e bootsplash Feb 11 21:35:42 JustinP: what nope? Feb 11 21:35:46 03justinp 07org.oe.dev * r52ebd988... 10/packages/efl/ (4 files): efl: bump PRs Feb 11 21:35:51 zecke: there are binaries in it that another package needs Feb 11 21:36:18 JustinP: I hate your 'work' around and beating up on packages instead of investing time to fix the real issue Feb 11 21:36:29 JustinP: what kind of binaries is in a lib* package? Feb 11 21:36:36 JustinP: a libfoo.so.1.2.3 Feb 11 21:36:51 JustinP: and if you link against it, you will automatically RDEPEND on it Feb 11 21:36:52 anyone know what's going on with zlib? Dropbear depends on it, but it doesn't emit and ipk and therefore dropbear fails (missing libz.so)? Feb 11 21:37:02 zecke: it' not linked Feb 11 21:37:13 JustinP: is it a plugin or such? Feb 11 21:37:18 zecke: and I've tried to fix the fucking issues but bitbake keeps getting in my damn way Feb 11 21:37:54 JustinP: well fix bitbake, but bitbake is not doing lib* munging Feb 11 21:38:19 now....how do I *stop* the lib* munging for one of the packages? Feb 11 21:39:09 JustinP: is this the debian.bbclass? Feb 11 21:39:25 zecke: I have no idea Feb 11 21:39:41 zecke: AFAIK nothing inherits debian for OZ packages... Feb 11 21:39:52 but maybe there's some magic I'm missing Feb 11 21:42:27 JustinP: well, is it a plugin or why don't you link against it? Feb 11 21:42:42 I said it's a binary Feb 11 21:42:51 a *binary* Feb 11 21:42:56 JustinP: why is this in a lib* package? Feb 11 21:42:58 which is run by the thing which depends on it Feb 11 21:43:03 ask raster Feb 11 21:43:12 edje is both a lib and a compiler Feb 11 21:43:15 JustinP: well libs are elf binaries too Feb 11 21:43:29 mmm Feb 11 21:43:34 edje_cc is the compiler Feb 11 21:43:42 but its not a lib as afar ai i know Feb 11 21:43:42 emte: yes Feb 11 21:43:51 fas as* Feb 11 21:43:51 emte: yes, edje is a lib Feb 11 21:44:00 edje is but nit edje_cc Feb 11 21:44:03 not* Feb 11 21:44:09 emte: any e stuff with themeing needs ot Feb 11 21:44:16 emte: and it's part of the same compile Feb 11 21:44:36 mmm Feb 11 21:44:54 JustinP: that doesn't mean you need to put it into the same package Feb 11 21:44:54 i am not sure if i agree that it "needs" it Feb 11 21:45:20 the themes need to be compiled to be used, but you dont need edje_cc to use the themes after they are compiled Feb 11 21:46:44 the only one i think which breaks that rule is embryo Feb 11 21:47:25 fucking A, why isn't anyone listening Feb 11 21:47:38 emte: I *KNOW* Feb 11 21:47:40 i'll have to remember to clarify that with raster otherwise i'll run into issues with my wm Feb 11 21:48:11 zecke: I'm not *TRYING* to put them in the same package. I'm trying to add a edje-utils PACKAGE which is *not* renamed to libedje-utils Feb 11 21:48:44 zecke: since bitbake has some kind of issue with RDEPENDing on lib* packages Feb 11 21:48:50 it says there's no buildable rprovider Feb 11 21:49:02 but forcing the do_rootfs of the image works fine Feb 11 21:49:31 JustinP: sounds like you want to take that up with RP Feb 11 21:49:48 JustinP, how about cheating and just compiling it static and skiping the runtime dep? Feb 11 21:49:52 why's that? Feb 11 21:50:08 emte: WTF are you talking about? Feb 11 21:50:10 emte: I'm not talking about a library Feb 11 21:50:18 emte: the auto-depending on libs works fine Feb 11 21:50:26 emte: I'm talking about depending on edje_cc Feb 11 21:50:31 emte: please.... Feb 11 21:50:46 oh, i thought you ment the other direction Feb 11 21:51:02 edje_cc depending on libraries Feb 11 21:51:07 no Feb 11 21:51:11 that works fine, of course Feb 11 21:55:38 how does gcc handle the issue? Feb 11 21:56:03 or does it? Feb 11 21:56:54 * JustinP looks Feb 11 21:57:25 off hand i'd think it would have the same problem with it's language support library files Feb 11 22:00:21 * JustinP has no idea where libgcc comes from Feb 11 22:18:55 damn it Feb 11 22:19:00 why is it renaming this! Feb 11 22:19:14 * JustinP hack Feb 11 22:19:15 s Feb 11 22:29:04 JustinP: due debian.bbclass inherited in familiar.conf and oz.conf Feb 11 22:32:37 zecke: ok Feb 11 22:32:58 zecke: does debian.bbclass do the lib* stuff? is there a way to stop is for one PACKAGE entry? Feb 11 22:33:04 * JustinP is hacking it with a second bbfile Feb 11 22:33:47 JustinP: I'm not too sure if you can prevent it Feb 11 22:37:10 zecke: it's fine, I'll just add a new bbfile which makes the packages I need Feb 11 22:37:18 well, new bbfiles... Feb 11 23:16:39 n8 Feb 11 23:18:53 gah Feb 11 23:19:03 CoreDump|home: some more commits coming... Feb 12 00:17:47 pb__: could we add a gpe.handhelds.org to the HOMEPAGE in the gpe.bbclass (if that exists) Feb 12 00:50:58 JustinP: like I said, this is a bug in bitbake Feb 12 00:51:06 JustinP: pester RP to fix it Feb 12 00:52:27 03rwhitby 07org.oe.dev * r4a7910f6... 10/ (3 files in 3 dirs): ixp4xx: Updated ixp4xx-header.patch for 2.6.16 Feb 12 00:54:36 JustinP: not that the situation had been perfect before (you'd basically add dependencies on the renamed packages) but at least the build wouldn't blow up Feb 12 04:41:48 what is osb-jscore? Feb 12 04:41:56 google isn't very useful on this, no homepage Feb 12 04:43:43 only hints that it's something Apple wrote Feb 12 04:45:41 rwhitby: ping, what are you doing to the poor defenseless OE tree? Feb 12 04:45:47 actually... Feb 12 04:45:53 it's justinp Feb 12 04:45:57 ah hah Feb 12 04:46:02 monotone: 4a7910f6f324ae55c1f42b4a22cbea6651e48ced rwhitby@nslu2-linux.org 2006-02-11T23:03:46 Feb 12 04:46:05 monotone: 8ea0fe4b0de92b762636231b067ef6a7f6137d01 justinp@openembedded.org 2006-02-11T21:33:12 Feb 12 04:46:15 JustinP: pingage. what'd-ya break now ? :P Feb 12 05:00:33 so guys, if i follow the GettingStarted procedure, bitbake will build the arm chaintools and then start to build packages ? Feb 12 05:02:19 CSMan: or WILL it!!!!!? Feb 12 05:02:31 with your mind powers *picture laser beams* Feb 12 05:02:47 CSMan: yeah, there's some tips though you ought to know Feb 12 05:03:38 like, we'd want to know which branch you're working with (org.openembedded.oz354fam083 or org.openembedded.dev) Feb 12 05:03:53 what your target platform is, and build cpu type is Feb 12 05:05:16 also note that some of the URLs are prone to damage due to changes in DNS availability for OE and related websites. three you may be interested in which have recently changed include: bugs.treke.net, oe.handhelds.org, and (if compiling openzaurus) openzaurus.sf.net Feb 12 05:05:50 i just monotuned .dev =P Feb 12 05:05:54 target is arm Feb 12 05:05:58 (ipaq) Feb 12 05:06:11 shadows: what urls ? Feb 12 05:08:49 * NAiL merges the monotone heads Feb 12 05:20:32 ~lart CSMan for not reading what shadows says Feb 12 05:20:32 * ibot strangles CSMan with a 9-pole serial cable for not reading what shadows says Feb 12 05:20:46 NA|Zzz: thanks Feb 12 05:21:10 NA|Zzz: did you push the changes? Feb 12 06:01:42 should i leave CVS_TARBALL_STASH = "http://www.oesources.org/source/current/" ? Feb 12 06:04:32 shadows: I didn't break anything Feb 12 06:04:41 shadows: I pretty much always commit a merged head Feb 12 06:05:03 shadows: other people commit to one of the other servers and the heads don't come together until later...and get unmerged Feb 12 06:06:21 somebody hit the hydra on a head Feb 12 06:06:26 made it confuzzled :/ Feb 12 06:06:45 i commented DISTRO_CHECK in familiar.conf Feb 12 06:06:48 shadows: an unmerged tree is a hydra Feb 12 06:07:20 * JustinP pulls Feb 12 06:07:36 shadows: you can always monotone update -r justinp's head ;-) Feb 12 06:11:45 i'll lop it off with cut Feb 12 06:11:52 * shadows looks embarassed Feb 12 06:11:57 sorry man, i don't mean that Feb 12 06:12:02 i'm in a foul mood :( Feb 12 06:13:24 shadows: pushing a merged rev right now Feb 12 06:13:43 shadows: you *can* merge them yourself, BTW Feb 12 06:13:58 shadows: you just have to deal withhaving revs in your DB which aren't in the main one Feb 12 06:14:13 uhmmm , i don't see any BUILD_OS in local.conf Feb 12 06:14:15 do i have to add it ? Feb 12 06:14:21 shadows: just don't ever push them if you do get commit access (i.e. start from a new DB) Feb 12 06:14:34 CSMan: what machine/distro do you want? Feb 12 06:14:42 CSMan: you should only have to set MACHINE and DISTRO Feb 12 06:14:48 CSMan: the rest will be set by those Feb 12 06:14:53 JustinP: ah, good advice. noted Feb 12 06:15:11 shadows: most of the time a merge has no problems Feb 12 06:15:21 shadows: pushed a merge to ewi Feb 12 06:15:30 monotone.vanille.de seems to be down... Feb 12 06:15:44 i've taken to an update script which updates from both Feb 12 06:16:01 yeah, i set machine to h3900 and distro to familiar, but in the GettingStarted page it gives instructions for freeBSD Feb 12 06:16:06 JustinP: some of the gaim devs pushed a workaround for the funky strftime problem Feb 12 06:16:16 JustinP: would like some help testing it :) Feb 12 06:16:22 (and i hope i don't have to rebuild the kernel) Feb 12 06:17:00 CSMan: ? the GettingStarted page should have instructions for installing the prereqs on various host machines Feb 12 06:17:13 shadows: I'm working on my e-image right now... Feb 12 06:17:18 shadows: building from scratch Feb 12 06:17:23 shadows: up to evas-x11 Feb 12 06:17:37 actually, I'm having a strange problem with my current e-image...no GPE progs will start up Feb 12 06:17:45 they complain about pango modules and no xpm support.... Feb 12 06:18:19 yay Feb 12 06:18:22 sounds like a chore Feb 12 06:20:09 at least it all builds now Feb 12 06:20:14 and my menu converter works Feb 12 06:20:20 ok, off for a bit again Feb 12 06:20:27 ~lart person who committed a reverse patch Feb 12 06:20:28 * ibot takes out person who committed a reverse patch with the trash Feb 12 06:20:38 great rhyming, ibot Feb 12 06:29:13 it's not a reverse patch, but it's really not necessary either Feb 12 06:40:34 shadows: ? Feb 12 06:40:44 well Feb 12 06:40:45 shadows: perhaps it was a disapprove? Feb 12 06:40:53 gaim cvs head was updated to include a work around Feb 12 06:41:04 making that part of the commit completely unnecessary Feb 12 06:41:22 somebody is building gaim ? Feb 12 06:41:35 with all transports ? Feb 12 06:41:51 yeah, i am going through all packages for gpe-image target and making them compile with gcc4 4.0.2 Feb 12 06:42:15 gaim was broken a long time before this Feb 12 06:42:31 the only one i tried was from familiar 0.8.2 Feb 12 06:42:38 and it only had jabber i think Feb 12 06:42:58 so far what i do is run it from another machine using X forwarding =P Feb 12 06:42:59 anyone know anything about pango or xpm support? Feb 12 06:43:22 very little Feb 12 06:44:09 * JustinP will have to delve.... Feb 12 06:45:30 will have to build a gpe-image and look at the installed progs... Feb 12 06:46:57 i'm getting closer Feb 12 06:47:46 now that i've poked what i need to poke for gaim upstream and now the OE bug ticket, going to continue on with making gpe-image a workable target for gcc4 cross initial Feb 12 06:48:55 ^_^ Feb 12 06:49:12 I'm glad someone is taking on this, it does need to be done eventually Feb 12 06:49:32 if you can, try to push your patches upstream as well Feb 12 06:51:55 thanks for the encouraging words Feb 12 06:52:27 I just know that it's a horribly large problem and I really have enough to deal with right now.... Feb 12 06:52:39 it's not that bad Feb 12 06:52:54 most packages have no issues Feb 12 06:53:22 it's just a handful that have obviously incorrect coding practices Feb 12 06:53:32 like sqlite Feb 12 06:53:39 and gaim Feb 12 06:53:51 both executed code on the host machine to determine output for the target Feb 12 06:54:04 that's not a gcc3/4 issue, it's just a bad freaking idea Feb 12 06:54:24 yeah Feb 12 06:54:25 sqlite ? Feb 12 06:54:42 sqlite can (and will) be worked around using the method documented in its source code Feb 12 06:54:47 of course autotools are just a big hack to begin with... Feb 12 06:56:33 epsilon?? Feb 12 06:56:45 why is it building epsilon.... Feb 12 06:56:47 :-p Feb 12 06:57:18 lovely Feb 12 06:58:46 hmmm...maybe it is normal...it's just one that I usually don't have to deal with :-) Feb 12 06:59:36 JustinP: i've not heard of epsilon as a software package Feb 12 06:59:48 * shadows pokes gtkwebcore Feb 12 07:01:05 hi ! anyone knows why 1 MegaFlop = 10^6 flops/s ? Feb 12 07:02:03 ... Feb 12 07:02:10 shadows: it's in EFL Feb 12 07:02:32 JustinP: is Jenna someone we know? Feb 12 07:03:00 shadows: do u respone to someone u know ? didnt see that in the channel rules Feb 12 07:03:49 spelling out the word "you" helps, it's only two extra letters and lessens my headache. Feb 12 07:04:32 * JustinP agrees Feb 12 07:04:40 Jenna: no, I don't know Feb 12 07:05:18 when did i get to be such a bastard Feb 12 07:05:38 * shadows thinks aloud "erm... monday... no, no it was after monday. maybe tuesday" Feb 12 07:07:49 * JustinP laughs Feb 12 07:08:13 I bet it has a lot to do with peoples' bad coding practices and having to fix their mistakes.... Feb 12 07:08:14 JustinP: k np. found it Feb 12 07:08:26 heh Feb 12 07:08:36 i should have seen that one coming Feb 12 07:08:43 argh! doing it again. Feb 12 07:09:04 i'm beginning to understand the purpose of repeat lartings Feb 12 07:09:57 JustinP: you by chance know the purpose of the -pedantic CFLAG? Feb 12 07:10:10 i'm having trouble finding it documented what that does in lay terms Feb 12 07:13:01 hehe Feb 12 07:13:02 no Feb 12 07:13:22 I can code and I can compile, but the fine points of gcc and autofoo are beyond me Feb 12 07:13:27 closest mention is that in one gcc version it's called pedantic, in the other it's -fpermissive Feb 12 07:13:30 oh Feb 12 07:13:46 sorry Feb 12 07:13:51 i want to grab it with my hands, shake it and scream "WHAT DO YOU WANT!?" Feb 12 07:14:06 oh well, patching it out works Feb 12 07:14:14 You can always just check the gcc source Feb 12 07:14:22 yeah i did that once Feb 12 07:14:26 that's kind of a strange flag name... Feb 12 07:14:31 see these scars? *points on wrists* Feb 12 07:15:31 it looks to me like it means "point out every little thing which doesn't conform precisely to spec" Feb 12 07:15:44 hm Feb 12 07:15:58 with or without erm Feb 12 07:16:03 i.e. be pedantic Feb 12 07:16:30 oh okay Feb 12 07:16:54 that helps, some Feb 12 07:19:16 http://peter.hates-software.com/2004/08/20/6550cefa.html Feb 12 07:19:34 first hit on google for: gcc pedantic Feb 12 07:20:00 gcc is always so pedantic... like the old Borland compiler... :) Feb 12 07:20:08 hmmm Feb 12 07:20:21 i was looking at gcc documentation for it Feb 12 07:20:33 how could i forget to google? it is unthinkable Feb 12 07:21:35 bollocks to you all, i'm updating gtkwebcore and submitting bug reports Feb 12 07:22:27 good luck Feb 12 07:22:39 yay, e-wm is compiling Feb 12 07:23:21 why do we stop the image loading hrm.... NRCit Feb 12 07:23:35 gtk-webcore/files/stop-load.image-loading.patch Feb 12 07:26:06 * JustinP prepares more revisions for pushing Feb 12 07:33:55 * JustinP pushes Feb 12 07:34:24 the edb,embryo,edje-utils packages are finally working Feb 12 07:34:35 although they not compile twice :-( Feb 12 07:35:24 not=now Feb 12 07:42:09 03justinp 07org.oe.dev * re00645b1... 10/classes/efl.bbclass: efl.bbclass: include is now part of -utils packages, not -dev packages Feb 12 07:42:14 03justinp 07org.oe.dev * rb9a9d493... 10/packages/efl/ (6 files): Feb 12 07:42:14 edje, embryo, edb: split out binary programs into -utils packages again Feb 12 07:42:14 - This time the -utils packages have their own bbs so they don't get their names auto-munged and so can be RDEPENDed on Feb 12 07:42:18 03justinp 07org.oe.dev * r6dc5369b... 10/packages/e17/e17-gpe-menu-convert_0.2.bb: e17-gpe-menu-convert: put back RDEPEND on edje-utils now that it's fixed Feb 12 07:54:40 shadows: what's the problem with my checkins to org.oe.dev? Feb 12 07:55:11 rwhitby: that was a snafu, now it is okay Feb 12 07:55:20 hydras scare me Feb 12 07:55:38 rwhitby: think it was justinp, not you Feb 12 07:57:53 in unrelated events, opie-image is going to suck for me, when i go through and clean up all dependent packages to compile with gcc4 Feb 12 07:58:17 C code isn't so bad as the C++ code differences of gcc3 and gcc4 Feb 12 07:58:56 shadows: hydras are normal for distributed configuration management systems. It's only hydras that cannot be resolved automatically which scare me. Feb 12 07:58:57 shadows, your maintaining all of opie now? Feb 12 07:59:23 * shadows hides in a bucket and shouts "negatory! captain!" Feb 12 07:59:59 focusing on gpe-image dependants for now Feb 12 08:00:11 i'm up to the gtk-webcore stuff currently Feb 12 08:04:34 shadows: it's no-one's fault, really Feb 12 08:04:51 shadows: it's part of the distributed nature of the syste, Feb 12 08:04:53 m Feb 12 08:14:32 hey JustinP how much do you understand about eet? Feb 12 08:17:03 emte: nothing Feb 12 08:18:01 emte: I'm very ignorant of the code itself, all I know is that it's some kind of low-level storage system...I think....which edb build upon Feb 12 08:18:10 lol Feb 12 08:18:55 i guess that descripes part of it Feb 12 08:19:00 describes* Feb 12 08:19:12 i think i figured it out anyway Feb 12 08:19:29 just has a bit of a silly convention when using it Feb 12 08:20:04 all of efl is silly convention.....it's OO without the OO... Feb 12 08:20:18 nah this was a bit more than that Feb 12 08:20:36 i cant pass EET data directly, only via a pointer Feb 12 08:20:55 interesting... Feb 12 08:21:19 easy change tho using c++ :) Feb 12 08:21:43 OO without the OO, sounds like gaim source code Feb 12 08:21:51 lol Feb 12 08:22:04 e is all objective-c Feb 12 08:22:14 emte: ? Feb 12 08:22:22 emte: no, I'm pretty sure it's C Feb 12 08:22:22 there are many good reasons for it tho Feb 12 08:22:52 yes it is c Feb 12 08:23:05 objective-c is what Mac OS X uses...it's C with objects and smalltalk's "message" syntax Feb 12 08:23:16 kind of fscked up if you ask me Feb 12 08:23:25 smalltalk is cool, but why mix syntaxes.... Feb 12 08:23:46 JustinP, embryo is based on smalltalk from what i understand Feb 12 08:23:56 is it? Feb 12 08:24:01 well, that's still not efl Feb 12 08:24:04 same concept Feb 12 08:24:06 it's embryo Feb 12 08:24:31 efl itself is all C Feb 12 08:24:54 yes with a very heavy ammount of abstraction and protection layers Feb 12 08:25:59 i cant remember ... someone in here was working on the c++ wrappers for it tho Feb 12 08:27:01 now to make eet compress my enviroment variables Feb 12 08:28:07 emte: it's mickeyl Feb 12 08:28:10 emte: efl++ Feb 12 08:29:01 ah Feb 12 08:30:27 hi all Feb 12 08:49:45 i think that's enough work for today Feb 12 08:50:04 JustinP: very close to making all the gtk-webcore junk compile, bugs have been filed Feb 12 08:51:11 shadows: I saw, very copious Feb 12 08:51:41 i'm in a zone, when i lose my buzz tomorrow from being sick, i don't want to forget all this Feb 12 08:52:18 Hmmm, trying to build the opie-image target, but it's failing on jlime **** ENDING LOGGING AT Sun Feb 12 10:59:58 2006