00:16.22 | *** join/#oe jott_ (n=j@e178074008.adsl.alicedsl.de) |
00:19.10 | *** part/#oe tester (n=tester@i53870DFD.versanet.de) |
00:20.52 | *** join/#oe marcan (n=marcanso@160.10.7.146) |
00:33.47 | *** join/#oe tuxero2 (n=tuxero@200.55.84.122) |
00:34.01 | tuxero2 | hi people |
00:35.41 | tuxero2 | somebody know what happened to openzaurus.org domain? a nslookup gives not existant entries |
00:36.14 | kergoth | the bill didnt get paid. will take care of it shortly |
00:37.38 | tuxero2 | oh, i see |
00:37.57 | tuxero2 | is the project hosted anywhere else? |
00:38.37 | shadows | kergoth: could you *please* change the #oz topic to reflect the websites for bugtracker, openzaurus, ? |
00:38.40 | tuxero2 | on #openzaurus shadow answered that |
00:39.05 | tuxero2 | is't hosted on openzaurus.sf.net |
00:42.24 | JustinP | is anyone around who can try to build evas-x11 for me? |
00:43.17 | mreimer | JustinP: I can, later. I'm building in .dev from scratch, on glibc now |
00:45.41 | JustinP | mreimer: I'd appreciate it |
00:45.51 | JustinP | mreimer: let me know if it packages the main package |
00:46.05 | mreimer | JustinP: ok. it will be a while |
00:46.11 | JustinP | mreimer: and if it build evas-x11 packages or libevas packages |
00:47.53 | JustinP | on my way out |
00:58.05 | *** join/#oe dijenerate (n=dijenera@72.22.141.126) |
01:00.00 | *** join/#oe _drak0__ (n=rob@user-10cmeb8.cable.mindspring.com) |
01:05.48 | JustinP | mreimer: I just started a new build from the "glibc done" point |
01:06.04 | mreimer | mine is currently packing glibc |
01:06.31 | JustinP | I'm having a very strange problem |
01:06.32 | shadows | erg. libexpat versus libxml |
01:06.38 | shadows | what should be used? |
01:06.47 | mreimer | expat is smaller |
01:06.58 | JustinP | evas-x11 worked fine yesterday but today the splitting isn't working right.... |
01:07.14 | mreimer | NOTE: package gcc-cross-3.4.4: started |
01:07.17 | mreimer | gonna be a while |
01:07.41 | JustinP | I have that done too :-) |
01:07.50 | JustinP | I keep a copy of tmp from after gcc-cross |
01:08.20 | shadows | o-kay, need to add in expat-2.0.0 then |
01:09.27 | *** join/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
01:12.25 | JustinP | mreimer: still going to take forever for me...have to compile diet-x11 and all |
01:12.35 | JustinP | just finished jpeg, though ^_^ |
01:12.49 | mreimer | maybe by tomorrow :-) |
01:12.56 | JustinP | oooh, already starting eet. You can get efl started ptretty quick |
01:13.02 | *** part/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
01:13.11 | mreimer | still on gcc-cross :-( |
01:14.00 | JustinP | yeah, glibc and gcc-cross are the worst 2 |
01:14.18 | shadows | *cough* binutils *cough* |
01:14.27 | JustinP | is that one long too? |
01:14.58 | shadows | if you build all possible targets, i think it may be the longest GNU package to build |
01:15.19 | shadows | t2 uses it as a reference case |
01:15.26 | JustinP | ok |
01:15.37 | JustinP | well, I'm not building for all targets....why would I want that? ;-) |
01:15.51 | shadows | :) |
01:20.10 | JustinP | not to figure out this other problems.... |
01:20.13 | JustinP | -s |
01:20.44 | mreimer | module-init-tools-cross |
01:21.06 | JustinP | ? |
01:21.11 | JustinP | ncurses |
01:22.13 | shadows | | /usr/bin/install: cannot create regular file `/usr/share/man/man1/xmlwf.1': Permission denied |
01:22.16 | shadows | derh? |
01:22.23 | mreimer | I started this build for handhelds-pxa-2.6 |
01:22.47 | JustinP | mreimer: which machine is that? |
01:22.51 | JustinP | shadows: did it kill the build? |
01:23.06 | mreimer | JustinP: my build host? sempron 2400 (1.6GHz) |
01:23.10 | shadows | i don't know what i'm doing, really. i was trying to add a bb for expat 2.0.0 |
01:23.20 | shadows | using the previous expat bb version as a template |
01:23.44 | shadows | doesn't autotools_do_configure handle the man page configuration var? |
01:24.36 | JustinP | shadows: it should.....but there are times when the makefiles aren't set up right |
01:24.51 | JustinP | mreimer: I meant what machine is the kernel for |
01:25.00 | mreimer | JustinP: h2200 |
01:25.27 | shadows | JustinP: i see no mention of 'mandir' in the output of the log file |
01:25.43 | shadows | err |
01:25.45 | shadows | no there it is |
01:25.55 | shadows | --mandir=/usr/share/man |
01:26.13 | shadows | so erm, what am i supposed to be making this do |
01:26.47 | shadows | with Portage we had a sandbox, and wrapper functions and complexity |
01:27.05 | JustinP | bitbake/OE has complexity too |
01:27.18 | JustinP | you can try looking at the autotoolsbbclass and such |
01:27.24 | JustinP | actually, that mandir is probably right |
01:27.31 | shadows | yeah |
01:27.32 | JustinP | the DESTDIR is altered on install I think |
01:27.40 | shadows | oh okay, so check DESTDIR fooby |
01:27.47 | JustinP | I think |
01:27.57 | JustinP | I'm not a master of autoconf and friends |
01:28.10 | JustinP | only a few gleaned half-truths.... |
01:28.43 | JustinP | right now I'm trying to debug why my efl includes are installed in /home/papercrane/oe... within the image dir... |
01:29.57 | shadows | what the heck is INSTALL_DATA |
01:30.06 | JustinP | don't know |
01:30.22 | shadows | configure:19359:test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644' |
01:30.40 | shadows | what the hell? how to procede? |
01:31.56 | shadows | going to try autotoolsbbclass |
01:32.24 | JustinP | s.bb |
01:32.28 | shadows | no, that's already included |
01:32.28 | JustinP | I forgot a . |
01:32.39 | JustinP | yeah, but you might look into it for clues |
01:32.44 | shadows | inherit autotools lib_package |
01:32.46 | shadows | hmn |
01:32.57 | JustinP | diet-x11, woo |
01:33.17 | JustinP | shadows: I mostly resorted to sed hackery to fix my autofoo problems |
01:33.21 | shadows | oh |
01:33.30 | shadows | should /usr/bin/install be invoked? |
01:33.36 | shadows | that's the point i'm confused about |
01:33.42 | shadows | how are these files supposed to be installed |
01:33.53 | JustinP | ? |
01:34.10 | JustinP | install is just a file copier which can set attrs |
01:34.24 | JustinP | install is used to install the files to the "image" dir |
01:34.24 | shadows | yes, but should /usr/bin/install from the *host machine* be invoked |
01:34.35 | JustinP | ::shrug:: I don't see why not |
01:34.59 | JustinP | I don't believe a version is compiled.... |
01:35.03 | JustinP | of course I'm not sure |
01:43.52 | JustinP | on xext now |
01:43.55 | JustinP | won't be too long |
01:44.39 | shadows | it seems that something like libpng uses "make -e MAKEFLAGS= ... install" |
01:46.26 | JustinP | there goes evas-x11 :-) |
01:46.41 | JustinP | damn,....I know what's breaking the includes....it's my sed hackery :-| |
01:48.52 | *** join/#oe idealm (n=ideal@58.33.50.237) |
01:51.21 | shadows | patch good |
01:51.22 | shadows | sed bad |
01:52.44 | JustinP | well, evas-x11 still packaged wrong for me, so it wasn't my cache and all |
01:52.48 | JustinP | :-( |
01:54.10 | shadows | i think i found how to make expat-2.0.0 behave |
01:54.18 | shadows | needed to add a line to define man1dir |
01:56.44 | shadows | NOTE: the following files were installed but not shipped in any package: |
01:56.44 | shadows | NOTE: xmlwf.1 |
01:56.50 | shadows | what the heck does that mean? |
01:57.14 | JustinP | it means that: |
01:57.22 | JustinP | 1) it was installed in the / dir, which is wrong |
01:57.27 | shadows | ah |
01:57.28 | JustinP | 2) that is was not packages |
01:57.33 | JustinP | packaged |
01:57.54 | JustinP | the path displayed in that message is the path from the "image" or "sandbox" install dir |
01:57.54 | shadows | so like, it was installed in the root of the build dir? errr.. |
01:58.04 | shadows | oh okay, groking logs |
01:58.05 | JustinP | meaning, it's the full path after a hypothetical install |
01:58.59 | shadows | export mandir="/usr/share/man" |
01:59.01 | shadows | from the log |
01:59.02 | shadows | hm |
01:59.29 | shadows | man1dir="/home/jnc/opensource/openzaurus/build/oetmp/work/armv5te-linux/expat-2.0.0-r0/image${man1dir}" |
01:59.32 | shadows | from inside do_install |
01:59.35 | shadows | that looks incorrect |
01:59.58 | shadows | my guess is i should change this to closer match zlib, "man3dir=${D}${mandir}/man3" |
02:00.28 | shadows | okay, updated, going to try again |
02:04.01 | shadows | works! |
02:04.49 | JustinP | shadows: want to take a look at my problem? |
02:05.10 | JustinP | sounds like you have more autofoo karma than I do |
02:05.12 | JustinP | ;-) |
02:05.36 | shadows | hehe |
02:05.38 | shadows | sure? |
02:05.48 | JustinP | well, I have 2 issues right now... |
02:05.58 | JustinP | can you try building evas-x11? |
02:06.35 | shadows | yeah, it's going to be with gcc-4.0.2 cross though |
02:06.39 | *** join/#oe marcan_ (n=marcanso@160.10.7.145) |
02:06.42 | shadows | so that is kind of incompatible at the moment |
02:06.56 | JustinP | hmmmm...true....but it might work... |
02:07.03 | JustinP | urgh, probably not, though |
02:07.14 | shadows | let me resolve a thing or two with expat, which is the current hangup, then i'll go bugfix towards evas-x11 |
02:07.20 | JustinP | ok |
02:07.23 | JustinP | thx |
02:07.26 | shadows | should i be setting PR ? |
02:07.33 | shadows | i see some builds do, some do not |
02:07.37 | JustinP | yes |
02:07.40 | JustinP | always set a PR |
02:07.42 | shadows | okay |
02:07.43 | JustinP | PR = "r0" |
02:07.54 | JustinP | then up it whenever you make a change (and commit it) |
02:07.57 | shadows | if i see a build that does not set a PR, should i correct it? |
02:07.58 | JustinP | so that upgrades will work |
02:08.05 | shadows | i don't have commit access |
02:08.08 | JustinP | all build *should* have one..... |
02:08.24 | shadows | (unless i am unaware of something) |
02:08.26 | JustinP | if they don't (and no incude or inherit sets one) then file a bug...I think |
02:08.29 | shadows | okay |
02:08.32 | JustinP | sorry, wasn't aware of that |
02:08.41 | shadows | it's better that way, for now |
02:08.51 | JustinP | perhaps if you do more gcc4 stuff you'll get commit :-) |
02:08.54 | shadows | i'm prone to break things in the name of newer versions heh heh |
02:08.58 | shadows | yeah |
02:09.03 | JustinP | yeah, that's bad :-| |
02:09.10 | shadows | i am supposed to write a WPA HOWTO for oz.org |
02:09.18 | JustinP | I got it because I volunteered to maintain e17 |
02:09.24 | JustinP | :-) |
02:09.27 | shadows | hopefully i can keep OZ running on my Z long enough to get through a HOWTO writeup |
02:09.39 | shadows | currently waiting for a serial cable i bought |
02:09.51 | shadows | $50usd for the sharp Z SIO cable, not bad eh? |
02:09.56 | JustinP | not bad, no |
02:10.17 | shadows | they're going on eBay for 25.00 + 24.99 s/h |
02:10.21 | andrewy | SIO? |
02:10.33 | shadows | SharpIO, a type of legacy port on sharp hardware |
02:10.45 | shadows | includes historically the serial, JTAG, power, and USB |
02:10.49 | andrewy | ah |
02:11.14 | andrewy | i got one of those with my collie, didnt know they werent always included |
02:11.35 | shadows | i think it was standard with some collie sales |
02:11.52 | shadows | the cable is difficult to acquire now that the serialio.com cable is popular |
02:12.07 | shadows | the serialio.com cable does not properly convert levels, resulting in one-way communication only |
02:12.29 | andrewy | i see |
02:12.43 | JustinP | it's broken for the newer models |
02:12.46 | JustinP | works for older ones |
02:13.14 | shadows | JustinP: you should be able to "fix" the level conversion |
02:13.18 | shadows | it's actually out of spec |
02:13.29 | shadows | that's why the serialio.com cable is not functional |
02:14.07 | JustinP | you mean the zaurii are out of spec? |
02:14.29 | JustinP | I'm not surprised, it's not meant to be a functional port (user-side, that is) |
02:14.30 | shadows | i think that may also be accurate |
02:14.42 | JustinP | not in the newer ones |
02:14.46 | JustinP | at least |
02:14.51 | shadows | it's a sort of TTL port |
02:15.43 | shadows | i've got a URL which has this documented for sharp calculators, which may be relevent: http://my.ebay.com/ws/eBayISAPI.dll?MyeBay |
02:16.22 | shadows | i think ultimately it would be in our best interests to discover how to craft and use a jtag cable for sharp hardware |
02:16.23 | *** join/#oe tmbinc (i=XXX@dslb-082-083-088-176.pools.arcor-ip.net) |
02:16.34 | shadows | it doesn't seem so difficult, if we can find a source for the connectors |
02:16.55 | shadows | the rest is just oscilloscope kung-fu'ery |
02:17.21 | JustinP | I'm pretty sure people have done it... |
02:17.57 | shadows | none i have heard of, only a few for SL-5500 and those were people with 20+ years of business contact with Sharp |
02:18.49 | JustinP | ah |
02:18.54 | shadows | i'm tempted to place an order for 1k pcs of that connector type and ebay it to hell |
02:19.01 | shadows | charge 10 bucks a connector ;) |
02:20.00 | emte | shadows, some devices get convoluted trying to find an exposed trace to connect a jtag connector |
02:20.13 | shadows | hmm :/ |
02:20.15 | emte | part of thier "physical security" |
02:20.48 | emte | cellphones are a prime example |
02:21.12 | emte | you used to have dealer "programming" connectors exposed behind the batteries |
02:21.46 | emte | most cell companies have stopped doing that since people were using them to clone abd reprogram phones |
02:21.50 | emte | reprogram* |
02:22.01 | shadows | ah |
02:22.15 | *** join/#oe wrobbie (n=rob@cm17.sigma183.maxonline.com.sg) |
02:26.18 | shadows | http://bugs.openembedded.org/show_bug.cgi?id=672 |
02:26.23 | shadows | expat update to 2.0.0 |
02:26.30 | shadows | who wants to commit, you know you do! |
02:26.49 | shadows | as miyavix_visavis would say, the answer is in you |
02:29.22 | emte | is bugs finally back up? |
02:29.43 | emte | nope |
02:33.45 | shadows | add a line to your hosts file, 192.216.230.225 bugs.openembedded.org |
02:34.04 | shadows | it will keep your sanity engaged. |
02:46.08 | emte | lol |
02:46.46 | JustinP | trying to figure out where it's killing my damn package |
02:47.01 | emte | the -config thing still ? |
02:48.37 | JustinP | no |
02:48.39 | JustinP | fixed that |
02:48.56 | JustinP | bitbake treats FILES_${SRCNAME}-dev and FILES_${PN}-dev differently |
02:49.04 | JustinP | even though they may to the same thing.... |
02:49.16 | JustinP | may? |
02:49.22 | JustinP | map |
02:49.37 | JustinP | I've got a very random problem now.... |
02:49.42 | JustinP | evas-x11 isn't getting renamed to libevas |
02:49.53 | JustinP | and the main package isn't being built as it's "empty" |
02:50.13 | JustinP | grrrrr! |
02:50.23 | JustinP | the package evas-x11 is being populated twice |
02:51.00 | emte | ... |
02:51.19 | JustinP | how fun |
02:51.19 | JustinP | NOTE: packages = evas-x11 evas-x11-doc evas-x11-dev evas-x11-locale evas-x11 evas-x11-themes evas-x11-dev evas-x11-examples |
02:51.23 | JustinP | NOTE: pkg = evas-x11 |
02:51.25 | JustinP | NOTE: pkg = evas-x11-doc |
02:51.28 | JustinP | NOTE: pkg = evas-x11-dev |
02:51.30 | JustinP | NOTE: pkg = evas-x11-locale |
02:51.33 | JustinP | NOTE: pkg = evas-x11 |
02:51.35 | JustinP | NOTE: pkg = evas-x11-themes |
02:51.38 | JustinP | NOTE: pkg = evas-x11-dev |
02:51.40 | JustinP | NOTE: pkg = evas-x11-examples |
02:51.43 | JustinP | aha |
02:51.45 | JustinP | it's my PACKAGES += |
02:51.48 | JustinP | still don't know why evas-x11 doesn't work and embryo does... |
02:51.53 | emte | lol |
02:54.27 | JustinP | is it possible to make packaes.split() also make the entries unique? |
02:54.29 | emte | hmm |
02:54.45 | emte | cmon edje ... go transparent |
02:59.08 | JustinP | ibot: botmail for mickeyl, how can I make an array in python have only unique values? |
03:02.22 | emte | do a search for duplicates i'd think |
03:07.48 | JustinP | oh hell yes |
03:08.04 | JustinP | of course I can't *commit* this change.....at least not without discussion |
03:08.21 | JustinP | about damn time I figured out this problem |
03:08.58 | JustinP | ok, bbiab |
03:14.40 | shadows | hooray for Justin |
03:46.05 | JustinP | ~lart package.bbclass |
03:48.08 | *** join/#oe Timelord (n=TL@4.78.4.43) |
03:53.23 | *** join/#oe _drak0_ (n=rob@user-10cmeb8.cable.mindspring.com) |
03:57.56 | *** join/#oe dkey (n=dkey@L0002P26.dipool.highway.telekom.at) |
03:58.16 | JustinP | ibot: botmail for mickeyl, I figured it out. I have a patch for package.bbclass to use a set to make the PACKAGES unique |
04:17.08 | *** join/#oe benlau (n=benlau@221.125.13.158) |
04:21.26 | *** join/#oe kfm (n=kfm82@p54BEE4E7.dip.t-dialin.net) |
04:22.55 | shadows | JustinP: bug #? |
04:24.05 | JustinP | shadows: for? |
04:24.19 | shadows | your doodle thinger |
04:24.26 | JustinP | doodle? |
04:24.33 | shadows | patch? |
04:24.56 | JustinP | ummmmm..I should make one |
04:24.58 | JustinP | one sec |
04:30.58 | shadows | it helps if you add bugs.openemebedded.org to your hosts file |
04:37.02 | JustinP | shadows: bugs.treke.net |
04:37.04 | JustinP | shadows: http://bugs.treke.net/show_bug.cgi?id=674 |
04:37.35 | shadows | :) |
04:38.01 | shadows | it's simple as adding bugs.openembedded.org to your hosts file |
04:38.05 | shadows | makes everything work fine |
04:38.15 | shadows | http://bugs.openembedded.org/show_bug.cgi?id=675 |
04:38.22 | shadows | updates for libsvg |
04:38.34 | shadows | the patch to make gcc4 eat it wasn't so bad |
04:38.36 | shadows | only two lines |
04:39.32 | JustinP | I don't have time to submit them right now.... |
04:39.40 | shadows | JustinP: the ideal thing would be to warn and halt |
04:39.47 | shadows | so that duplicate cases are fixed |
04:39.59 | JustinP | I suppose |
04:40.31 | JustinP | I can think of ok reasons to have duplicates....but I suppose it should be "fixed"... |
04:40.37 | JustinP | ::shrug:: |
04:40.49 | JustinP | as long as it doesn't just eat packages like now |
05:19.15 | *** join/#oe Timelord (n=TL@4.78.4.43) |
05:22.03 | *** join/#oe alan| (n=alan@ARouen-152-1-48-234.w83-115.abo.wanadoo.fr) |
05:31.27 | *** join/#oe _drak0__ (n=rob@user-10cmeb8.cable.mindspring.com) |
05:42.38 | shadows | gah |
05:42.44 | shadows | libsvg build blew up |
05:54.49 | *** part/#oe benlau (n=benlau@221.125.13.158) |
06:08.35 | Zero_Chaos | how do I set oz354fam083? |
06:11.41 | shadows | it's decided when you checkout your branch |
06:12.06 | shadows | i.e. oz354fam083 is one of the branches in the oe monotone scm |
06:12.29 | shadows | use --branch=... i think |
06:12.39 | Zero_Chaos | okay, I'll try that |
06:13.08 | Zero_Chaos | nope |
06:13.39 | Zero_Chaos | I guess I'm meant to use the bleeding edge instead of the cutting edge |
06:19.14 | JustinP | Zero_Chaos: monotone --db=OE.db --branch=org.openembedded.oz354fam083 |
06:19.34 | *** join/#oe johnX (n=x@c-24-16-192-158.hsd1.wa.comcast.net) |
06:19.46 | Zero_Chaos | JustinP: can I use the same OE.db for that as well as .dev? |
06:19.55 | JustinP | yes |
06:20.01 | JustinP | it should have both |
06:20.06 | Zero_Chaos | really? that is wicked |
06:20.08 | JustinP | if you were pulling both.... |
06:20.09 | Zero_Chaos | thanks |
06:20.23 | Zero_Chaos | I've never pulled both... is there a faq somewhere? |
06:20.28 | Zero_Chaos | a setup guide? |
06:20.38 | JustinP | when you pull what do you do? |
06:21.34 | Zero_Chaos | monotone --db=/home/zaurus/src/build/conf/oe.db pull dominion.kabel.utwente.nl org.openembedded.dev |
06:21.41 | JustinP | that's the problem then |
06:21.54 | JustinP | you weren't pulling the other branch |
06:21.59 | JustinP | does the checkout fail? |
06:22.09 | Zero_Chaos | that command completes fine |
06:22.23 | Zero_Chaos | what should I do? |
06:22.41 | JustinP | you should then have a checkout |
06:22.56 | JustinP | however, you need to pull the latest for that branch |
06:23.08 | JustinP | <PROTECTED> |
06:23.39 | Zero_Chaos | okay, so I can have my line, and the one you just wrote in my update script, right? |
06:23.56 | JustinP | yes, but don't |
06:24.01 | JustinP | use monotone --db=/home/zaurus/src/build/conf/oe.db pull dominion.kabel.utwente.nl org.openembedded."*" |
06:24.05 | JustinP | with the quotes |
06:24.10 | JustinP | will pull both :-) |
06:24.23 | Zero_Chaos | JustinP: only both, or 100 branches that I don't want? |
06:24.48 | JustinP | there are only 3 |
06:24.57 | JustinP | and .dreambox barely changes |
06:25.23 | Zero_Chaos | JustinP: I'm very limited on space, can I pull each individually, or is that bad? |
06:25.29 | Zero_Chaos | I don't want anything I don't need |
06:25.35 | JustinP | Zero_Chaos: use one db |
06:25.50 | JustinP | Zero_Chaos: if you're worried, you *can* pull them seperately... |
06:25.54 | JustinP | Zero_Chaos: or you can use, say: |
06:26.14 | JustinP | Zero_Chaos: org.openembedded."{dev,oz354fam083}" |
06:26.19 | JustinP | I *think* that's right |
06:26.26 | Zero_Chaos | I'll check |
06:27.44 | Zero_Chaos | JustinP: I did it with no quotes, and it seems to be working.... |
06:27.57 | JustinP | ok |
06:28.09 | JustinP | as long as it's oulling revs you should be ok |
06:28.25 | Zero_Chaos | I sure seem to be. |
06:28.52 | JustinP | and it will probably take a while, depending on how long you haven't been pulling it |
06:28.58 | JustinP | how many revs? |
06:29.01 | Zero_Chaos | now I can just change my conf/local.conf to use org.openembedded.oz354fam083 instead or .dev and it should work right....right? |
06:29.11 | Zero_Chaos | JustinP: 4321 |
06:29.21 | JustinP | Zero_Chaos: pretty much |
06:29.25 | Zero_Chaos | JustinP: Revs in 390 |
06:29.32 | JustinP | Zero_Chaos: you should empty your tmpdir first |
06:29.41 | Zero_Chaos | I imagine those revs are for the new branch |
06:29.45 | JustinP | Zero_Chaos: or use another one |
06:29.46 | JustinP | yes |
06:29.50 | Zero_Chaos | JustinP: yeah, I figured |
06:31.35 | Zero_Chaos | JustinP: thanks for your help, time for sleepy |
06:31.37 | Zero_Chaos | later |
06:34.10 | *** join/#oe toi (n=pleemans@d5152D12D.access.telenet.be) |
06:35.38 | JustinP | Zero_Chaos: sleep well |
06:48.09 | *** join/#oe dijenerate (n=dijenera@72.22.141.126) |
06:56.11 | *** join/#oe dijenerate (n=dijenera@72.22.141.126) |
07:14.33 | CSMan | mreimer: i solved my icu build problem, it was a LC_ALL issue =P |
07:46.28 | shadows | could i please get some people testing http://bugs.openembedded.org/show_bug.cgi?id=540 |
07:46.52 | shadows | need volunteers with various targets and build platforms (amd64/ia32) |
07:55.06 | emte | not sure how many people actually have 32/64 systems |
07:56.16 | shadows | either one is fine |
07:56.25 | shadows | i want to verify what i'm doing is correct |
07:56.43 | emte | ... |
07:56.45 | shadows | the trouble is that sqlite assumes a lot of things unless you tell it otherwise, during the compile phase |
07:56.57 | emte | says its for 32/64 systems not 32 OR 64 |
07:57.01 | shadows | it makes stupid assumptions about the size of a pointer |
07:57.16 | shadows | amd64 and ia32 are exclusive |
07:57.37 | *** join/#oe gremlin[it] (n=gremlin@88.149.150.72) |
07:57.42 | emte | so your trying to test a hybrid patch on pure systems? |
07:57.49 | shadows | no |
07:58.10 | shadows | i need it tested on whatever platforms people have, especially if they have both platforms to test on |
07:58.29 | shadows | i'm trying it with zaurus c3000 target on amd64 host |
07:58.32 | shadows | more tests welcomed :) |
07:58.59 | shadows | for ia32 build hosts i want to verify that the patch is functionally equivillent to no patch |
07:59.16 | emte | then i apperently dont understand what the bug is for |
07:59.23 | shadows | and for amd64 build hosts i want to verify that it fixes the bug where libsqlite crashes and in a chain of unfortunate events causes tiny fonts |
07:59.24 | emte | ah |
08:00.06 | JustinP | I can test it later...busy right now |
08:00.18 | JustinP | remind me tomorrow or something... |
08:00.50 | shadows | sqlite has some code in the makefile that runs using the build host's cc, and executes that code on the build host, spitting out the size of a pointer of the build host environment onto stdout, which is then directed into a config.h file and used as a value for the target source compile. totally bollocks |
08:00.56 | shadows | super :) |
08:01.55 | shadows | emte: what the patch i've made does is explicitly sets a makefile define per the comments of sqlite, such that it defines the type which would otherwise be set by the bollocks'd code |
08:02.08 | shadows | a workaround, and should be effective if i got the type correct |
08:02.38 | emte | '-DINTPTR_TYPE int' |
08:02.42 | shadows | yep |
08:02.43 | emte | your refering to that i take it |
08:03.09 | emte | yeah that wont do anything on a 32bit host |
08:03.49 | shadows | 32bit host, 32bit target |
08:03.58 | shadows | it would have to be modified if we had a 64bit target |
08:04.04 | shadows | for 64bit host i'm hoping that works okay |
08:05.15 | shadows | i'm running through a gcc4 (4.0.2) compile on amd64 build host of gpe-image |
08:05.29 | shadows | so far i've patched up expat and libsvg |
08:05.38 | shadows | and now hopefully sqlite |
08:06.35 | emte | i am curious |
08:06.44 | emte | why dont you just test the host and adjust? |
08:07.08 | shadows | emte: the test should be for the target, not the host |
08:08.11 | shadows | emte: take a look at the code for sqlite if you have any further questions, i am open for suggestions |
08:08.12 | emte | but INT can vary is size from host to host even in ansii standards |
08:08.21 | emte | in* |
08:10.08 | shadows | ANSI |
08:10.45 | shadows | older standards define it as a unit of work dependent on CPU type |
08:10.49 | emte | yeah the extra i was for fun |
08:10.52 | shadows | :) |
08:11.35 | shadows | what do you think about moving oe's default compiler to something more recent |
08:11.38 | shadows | like gcc 4.0.2 ? |
08:11.56 | emte | bad idea right now |
08:12.04 | shadows | what depends on gcc3 ? |
08:12.08 | emte | i'd wait til 4.x was a bit more mature |
08:12.16 | shadows | i think gcc4 is mature |
08:12.17 | emte | most code |
08:12.29 | shadows | most code meaning what? |
08:12.31 | emte | i remember all the problems with the first few releases of 3.x |
08:12.48 | emte | legacy programming practices |
08:13.01 | emte | and non-maintianed code |
08:13.06 | emte | maintained* |
08:13.23 | shadows | OE is already dependent on gcc 2.95 |
08:13.28 | emte | no |
08:13.33 | shadows | which is pretty freaking ancient |
08:13.43 | emte | the sharp compiler is 2.95 |
08:13.46 | shadows | yeah, for 2.4.20 oz embeddix kernels |
08:13.47 | shadows | mmhm |
08:13.57 | emte | thats the only thing that uses 2.95 |
08:14.07 | shadows | out of the whole OE tree, that's the only one? |
08:14.13 | emte | yup |
08:14.16 | emte | that i know of |
08:14.20 | shadows | interesting |
08:14.32 | emte | familiar and OZ use 3.3.4 for the most part |
08:14.49 | emte | and i am pretty sure all the other projects do as well |
08:16.26 | emte | whee ... 1'st abstarction test passed |
08:16.38 | emte | the ra one too |
08:18.12 | shadows | thanks for the feedback |
08:18.19 | shadows | sleepytime for me :) |
08:19.10 | emte | yeah, i'll try to rememebr to get the patch after monotone is done |
08:34.45 | RP | JustinP: I'm afraid I have no access to macs. You could try disabling the DMA code in the driver though (its a #define near the top of the file) |
08:48.11 | *** join/#oe ar_ (n=ar@port-ip-213-211-231-88.reverse.mdcc-fun.de) |
08:56.29 | *** join/#oe pleemans (n=peter@d54C24BC0.access.telenet.be) |
09:07.34 | *** join/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
09:15.17 | *** part/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
09:22.13 | *** join/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
09:26.07 | *** join/#oe hufnus (n=slonsiki@DSL135-071.LABridge.com) |
09:41.38 | *** join/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
09:52.46 | *** join/#oe theturtle (n=theturtl@lns-bzn-51f-81-56-135-127.adsl.proxad.net) |
09:54.03 | *** join/#oe zap (n=zap@217.170.93.196) |
10:24.33 | *** join/#oe alan|home (n=alan@ARouen-152-1-111-22.w86-208.abo.wanadoo.fr) |
11:07.25 | *** join/#oe _alwin_ (n=ral@cable-81-173-164-172.netcologne.de) |
11:09.21 | *** join/#oe benlau (n=benlau@221.125.13.158) |
11:25.43 | *** join/#oe AvengerMoJo (n=alex@207.44.242.115) |
11:30.49 | *** join/#oe zecke (n=ich@88.134.3.107) |
11:32.15 | *** join/#oe incinerator (n=incinera@82-41-24-164.cable.ubr04.edin.blueyonder.co.uk) |
11:41.26 | *** join/#oe dkey| (n=dkey@L0006P20.dipool.highway.telekom.at) |
11:52.57 | *** join/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
12:05.46 | *** part/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
12:10.44 | *** join/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
12:12.09 | *** part/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
12:15.51 | *** join/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
12:18.56 | *** part/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
12:22.15 | *** join/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |
12:29.13 | *** join/#oe benlau (n=benlau@221.125.13.158) |
12:35.34 | *** join/#oe benlau (n=benlau@221.125.13.158) |
12:38.40 | *** join/#oe niklash (n=niklas@host86-135-155-84.range86-135.btcentralplus.com) |
12:39.46 | *** part/#oe benlau (n=benlau@221.125.13.158) |
12:44.28 | niklash | I'm trying to use the native gcc that is built in oe for gpe on familiar. |
12:44.54 | niklash | It seems to try to find libc.so.6 in /usr/lib rather than /lib. |
12:45.28 | niklash | Am I in the right irc channel? |
12:45.40 | niklash | Is this a bug in the metadata for this package? |
12:45.58 | niklash | Anyone know how to fix it? |
12:48.28 | niklash | If I symlink /lib/libc6.so.6 to /usr/lib/, then it'll try to find /usr/usr/lib/libc_nonshared.a |
12:49.06 | niklash | It seems to believe "/usr/bin/../../usr" is "/". |
12:49.29 | pb__ | 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? |
12:50.43 | niklash | pb_, if I run "gcc test.c" (a trivial hello world program), then it'll complain that it can't find libc.so.6. |
12:51.37 | niklash | I can ssh in and copy the exact error message if you want it, but that'll take a sec. |
12:52.59 | pb__ | yes, please |
12:55.57 | *** join/#oe XorA (n=dp@81-178-107-76.dsl.pipex.com) |
12:58.35 | niklash | pb_, http://pastebin.com/549689 |
12:59.51 | pb__ | what does /usr/lib/libc.so look like? |
13:00.26 | *** join/#oe Mardy (n=mardy@adsl-ull-209-101.42-151.net24.it) |
13:00.29 | *** join/#oe _drak0_ (n=rob@user-10cmeb8.cable.mindspring.com) |
13:00.43 | niklash | GOUTPUT_FORMAT(elf32-littlearm) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) ) |
13:00.47 | Mardy | hi all |
13:00.58 | niklash | s/GOUTPUT/OUTPUT/ |
13:03.16 | Mardy | if "a" is a int16_t, is "a - (a & 0xfff8)" equal to "a & 7" for any value of "a"? |
13:03.49 | niklash | Damn. I meant to try "mv /usr/lib/libc.so /lib", but typed libc.so.6. Guess I'll need to reflash now... |
13:08.41 | pb__ | That all looks OK. It sounds like the linker isn't behaving in quite the way that glibc wants. |
13:09.36 | CoreDump|home | hi |
13:09.50 | niklash | 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. |
13:10.15 | niklash | What I don't know is where /usr/bin/../../usr comes from. |
13:10.47 | niklash | At least that's my guess from looking at the output. |
13:11.45 | CoreDump|home | any got a fixed gaim.bb? |
13:12.03 | CoreDump|home | gaim_cvs |
13:12.32 | *** join/#oe zecke (n=ich@88.134.3.107) |
13:14.34 | *** join/#oe wrobbie (n=rob@cm17.sigma183.maxonline.com.sg) |
13:16.52 | zecke | hi |
13:16.57 | *** join/#oe benlau (n=benlau@221.125.13.158) |
13:20.29 | pb__ | hi zecke |
13:20.58 | pb__ | niklash: yeah. I guess that path must be hard-wired into ld. |
13:34.13 | *** join/#oe gremlin[it] (n=gremlin@88-149-149-238.f4.ngi.it) |
13:58.27 | *** join/#oe dan2003 (n=dan2003@cpc1-ware3-0-0-cust291.lutn.cable.ntl.com) |
14:06.46 | hrw | hi |
14:08.28 | CIA-4 | 03rwhitby 07org.oe.dev * r20f5c236... 10/packages/ (13 files in 3 dirs): ixp4xx-kernel: Added initial ds101 patchset from NAiL |
14:08.32 | CIA-4 | 03rwhitby 07org.oe.dev * r494f7afe... 10/packages/ (13 files in 3 dirs): disapproval of revision '20f5c236b9ebdf5e2fc0e5acea55f39e77588bb8' |
14:08.36 | CIA-4 | 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) |
14:08.41 | CIA-4 | 03rwhitby 07org.oe.dev * rc07516fb... 10/packages/linux/ixp4xx-kernel_2.6.16-rc2.bb: ixp4xx-kernel: Fixed i2c on nas100d (thanks to dwery) |
14:08.44 | CIA-4 | 03rwhitby 07org.oe.dev * rd75a82f1... 10/packages/linux/ixp4xx-kernel_2.6.16-rc2.bb: ixp4xx-kernel: Added 94-loft-setup |
14:08.49 | CIA-4 | 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) |
14:08.53 | CIA-4 | 03rwhitby 07org.oe.dev * r0a0aa499... 10/packages/linux/ixp4xx-kernel.inc: ixp4xx-kernel: Added support for building ds101 kernels. |
14:08.57 | CIA-4 | 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 |
14:09.01 | CIA-4 | 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 |
14:11.15 | gremlin[it] | 2.6.16 ?!?!?!?! |
14:11.49 | rwhitby | -rc2 |
14:11.51 | hrw | rwhitby: consider 2.6.15+2.6.16-rc2 as PV - less problem with upgrade to 2.6.16 final |
14:12.10 | rwhitby | hrw: good idea |
14:12.36 | hrw | rwhitby: we use it in OZ kernels |
14:12.38 | RP | The OZ kernels had the same issue |
14:12.44 | rwhitby | But I wonder whether the logic in ixp4xx-kernel which patches the kernel correctly will handle that ... |
14:12.56 | rwhitby | ixp4xx-kernel.inc that is |
14:12.57 | CoreDump|home | ~lart ecore |
14:13.48 | hrw | ~hail koen for split-feed script |
14:13.50 | ibot | ACTION bows down to koen for split-feed script and chants, "I'M NOT WORTHY!!" |
14:14.25 | shadows | gcc HEAD does not compile in current OE |
14:14.26 | shadows | :( |
14:14.37 | shadows | | checking for the %z format string in strftime()... configure: error: cannot run test program while cross compiling |
14:14.43 | shadows | now why would it go and do that |
14:15.18 | rwhitby | 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? |
14:16.00 | *** join/#oe reenoo (n=r@p5489C5E0.dip.t-dialin.net) |
14:16.12 | hrw | rwhitby: python is like german to me - know few words |
14:16.21 | rwhitby | same here |
14:16.40 | reenoo | afternoon |
14:16.47 | shadows | i mis-spoke |
14:16.55 | shadows | s/gcc/gaim/ |
14:17.07 | hrw | hm. need to use hh.org bugzilla again ;( |
14:17.26 | shadows | the gaim HEAD is package which does not compile, due to %z format error in do_configure phase |
14:18.39 | shadows | conftest.c:67: warning: conflicting types for built-in function 'strftime' |
14:18.45 | shadows | when it is being built with gcc4 |
14:18.46 | shadows | hm |
14:19.10 | shadows | how do i capture the output of the c source it is compiling? |
14:19.18 | shadows | i mean, to get the c source |
14:19.20 | shadows | so i can look at it |
14:19.30 | zecke | shadows: config.log and configure? |
14:19.39 | shadows | so, go through configure hrm |
14:25.20 | shadows | rather not-convenient |
14:27.34 | *** part/#oe benlau (n=benlau@221.125.13.158) |
14:34.42 | hrw | ~curse handhelds.org bugzilla admins for too much entries in product list |
14:34.43 | ibot | May you be reincarnated as a Windows XP administrator, handhelds.org bugzilla admins for too much entries in product list ! |
14:35.09 | *** join/#oe benlau (n=benlau@221.125.13.158) |
14:40.41 | *** join/#oe benlau (n=benlau@221.125.13.158) |
14:47.48 | hrw | cu |
14:48.46 | *** join/#oe bronson (n=bronson@pool-71-243-90-29.bos.east.verizon.net) |
15:02.23 | *** part/#oe benlau (n=benlau@221.125.13.158) |
15:04.53 | *** join/#oe memeruiz (n=memeruiz@201.194.192.98) |
15:06.01 | *** join/#oe benlau (n=benlau@221.125.13.158) |
15:06.03 | shadows | ~lart autotools borking gaim |
15:07.14 | *** join/#oe dan2003 (n=dan2003@86.13.233.36) |
15:21.59 | CIA-4 | 03pH5 07org.oe.dev * ra2365934... 10/ (3 files in 3 dirs): |
15:21.59 | CIA-4 | gaim_cvs: build fix |
15:21.59 | CIA-4 | <PROTECTED> |
15:21.59 | CIA-4 | <PROTECTED> |
15:36.14 | *** join/#oe benlau (n=benlau@221.125.13.158) |
15:37.54 | *** join/#oe benla1 (n=benlau@221.125.13.141) |
15:43.55 | shadows | super |
15:44.05 | shadows | i was going to submit a bug report about the strftime %z test |
15:44.09 | shadows | i guess he beat me to it |
15:44.29 | *** join/#oe poli (n=ca@CAcert-br/poli) |
15:45.49 | *** join/#oe dhr (n=hugh@72.56.139.67) |
15:50.39 | *** part/#oe benla1 (n=benlau@221.125.13.141) |
15:53.46 | *** join/#oe _drak0__ (n=rob@user-10cmeb8.cable.mindspring.com) |
15:54.54 | shadows | okay the next failure with gcc4 is osb-jscore |
15:55.06 | shadows | it's the "qualification" bug |
15:55.09 | shadows | already documented |
15:55.24 | shadows | i cannot find the patch mentioned in http://www.handhelds.org/hypermail/oe/40/4041.html |
15:55.28 | shadows | does anyone else have it? |
15:59.02 | *** join/#oe zap (n=zap@217.170.93.196) |
16:05.25 | *** join/#oe drw (n=drw@c-67-172-219-167.hsd1.tx.comcast.net) |
16:09.37 | *** join/#oe benlau (n=benlau@221.125.13.158) |
16:27.16 | *** join/#oe dijenerate (n=dijenera@72.22.141.126) |
16:28.03 | *** join/#oe _Titeuf (n=Titeuf@2m01.net) |
16:30.49 | *** part/#oe _Titeuf (n=Titeuf@2m01.net) |
16:55.29 | *** join/#oe gints|wrk (n=gints@195.244.141.102) |
16:59.23 | *** join/#oe minipanda (n=hzhang@219.236.21.137) |
17:01.04 | *** join/#oe bluebugs (n=cedric@LAubervilliers-151-11-32-8.w193-251.abo.wanadoo.fr) |
17:12.00 | *** join/#oe AvengerMoJ1 (n=alex@207.44.242.115) |
17:12.18 | *** join/#oe benlau (n=benlau@221.125.13.158) |
17:16.09 | *** join/#oe Minase (n=minase@reverie.encapsulated.net) |
17:18.00 | *** join/#oe Minase (n=minase@reverie.encapsulated.net) |
17:18.21 | *** join/#oe _guillermo (n=guillerm@dslb-084-062-143-199.pools.arcor-ip.net) |
17:24.12 | *** join/#oe alan|xchat (n=alan@ARouen-152-1-38-179.w83-115.abo.wanadoo.fr) |
17:31.02 | *** join/#oe benlau (n=benlau@221.125.13.158) |
17:31.55 | *** join/#oe _drak0_ (n=rob@user-10cmeb8.cable.mindspring.com) |
17:38.21 | *** join/#oe mreimer_ (n=mreimer_@wl-wa.vpop.net) |
17:49.19 | *** join/#oe aquadran_ (i=pablo@scummvm/undead/aquadran) |
17:53.30 | *** join/#oe benlau (n=benlau@221.125.13.158) |
17:58.40 | *** part/#oe mreimer_ (n=mreimer_@wl-wa.vpop.net) |
18:10.49 | *** join/#oe _alwin_ (n=ral@cable-195-14-254-205.netcologne.de) |
18:12.45 | CIA-4 | 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 |
18:12.50 | CIA-4 | 03hrw 07org.oe.dev * rab5c1cdb... 10/packages/sharp-binary-only/sharp-sdmmc-support.bb: |
18:12.50 | CIA-4 | sharp-sdmmc-support: unbreak it if kernel is not yet built - close #679 |
18:12.50 | CIA-4 | taken from .oz354fam083 |
18:13.01 | *** join/#oe katossi (n=guillerm@dslb-084-062-143-199.pools.arcor-ip.net) |
18:19.35 | *** join/#oe benlau (n=benlau@221.125.13.158) |
18:37.37 | *** join/#oe dan2003 (n=dan2003@cpc1-ware3-0-0-cust291.lutn.cable.ntl.com) |
18:41.17 | *** join/#oe alan|xchat (n=alan@ARouen-152-1-33-82.w83-115.abo.wanadoo.fr) |
19:23.06 | *** join/#oe alan|xchat (n=alan@ARouen-152-1-87-159.w86-195.abo.wanadoo.fr) |
19:37.52 | *** join/#oe gremlin[it] (n=gremlin@88-149-149-254.f4.ngi.it) |
19:38.59 | *** join/#oe Timelord (n=TL@4.78.4.43) |
19:41.20 | CoreDump|home | did anyone play with package_ipk.bbclass recently? |
19:42.38 | CoreDump|home | you're kidding right |
19:42.41 | Zero_Chaos | <PROTECTED> |
19:42.45 | CoreDump|home | hehe |
19:42.56 | CoreDump|home | probably for e-image-core |
19:43.38 | Zero_Chaos | 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 |
19:43.38 | CoreDump|home | well, "something" broke ecore-x11, and I'm almost sure it's coming from that bbclass |
19:43.53 | CoreDump|home | Zero_Chaos: thanks =) |
19:58.32 | *** join/#oe dkey (n=dkey@L0006P18.dipool.highway.telekom.at) |
20:03.56 | CoreDump|home | Zero_Chaos: YES |
20:04.02 | CoreDump|home | got the bug |
20:04.17 | Zero_Chaos | CoreDump|home: sweet |
20:04.24 | *** join/#oe Timelord (n=TL@4.78.4.43) |
20:11.50 | CoreDump|home | that was a nasty one :\ |
20:38.34 | *** join/#oe zecke (n=ich@88.134.3.107) |
20:38.40 | zecke | re |
20:41.07 | CSMan | 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 =/ |
20:47.05 | DataBeaver | I made libxine compile with GCC 4, what do I win? (And where do I send the patch?) |
21:17.01 | zecke | koen|away: where is out wish list for CELF? |
21:19.35 | zecke | DataBeaver: bugs.treke.net attach it |
21:19.41 | zecke | DataBeaver: and send it upstream to the xine people... |
21:35.28 | JustinP | so it's not possible to RDEPEND on a auto-munged lib* package |
21:35.43 | JustinP | grrrr |
21:36.18 | zecke | JustinP: well if you link to it |
21:36.25 | CIA-4 | 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 |
21:36.27 | zecke | JustinP: it will automatically on a lib* munged package |
21:36.30 | CIA-4 | 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 |
21:36.34 | CIA-4 | 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 |
21:36.37 | JustinP | zecke: nope |
21:36.38 | CIA-4 | 03justinp 07org.oe.dev * r48f276ac... 10/packages/efl/evas-x11_0.9.9.023.bb: evas-x11: --enable-buffer, edje_cc needs it |
21:36.43 | CIA-4 | 03justinp 07org.oe.dev * r883c5828... 10/packages/efl/evas.inc: evas.inc: remove unneeded do_configure |
21:36.48 | CIA-4 | 03justinp 07org.oe.dev * r967b737b... 10/packages/meta/task-e-x11.bb: task-e-x11-core: add new e bootsplash |
21:36.48 | zecke | JustinP: what nope? |
21:36.52 | CIA-4 | 03justinp 07org.oe.dev * r52ebd988... 10/packages/efl/ (4 files): efl: bump PRs |
21:36.57 | JustinP | zecke: there are binaries in it that another package needs |
21:37.24 | zecke | JustinP: I hate your 'work' around and beating up on packages instead of investing time to fix the real issue |
21:37.35 | zecke | JustinP: what kind of binaries is in a lib* package? |
21:37.42 | zecke | JustinP: a libfoo.so.1.2.3 |
21:37.58 | zecke | JustinP: and if you link against it, you will automatically RDEPEND on it |
21:37.58 | rwhitby | 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)? |
21:38.08 | JustinP | zecke: it' not linked |
21:38.19 | zecke | JustinP: is it a plugin or such? |
21:38.24 | JustinP | zecke: and I've tried to fix the fucking issues but bitbake keeps getting in my damn way |
21:39.00 | zecke | JustinP: well fix bitbake, but bitbake is not doing lib* munging |
21:39.26 | JustinP | now....how do I *stop* the lib* munging for one of the packages? |
21:40.15 | zecke | JustinP: is this the debian.bbclass? |
21:40.32 | JustinP | zecke: I have no idea |
21:40.47 | JustinP | zecke: AFAIK nothing inherits debian for OZ packages... |
21:40.58 | JustinP | but maybe there's some magic I'm missing |
21:43.33 | zecke | JustinP: well, is it a plugin or why don't you link against it? |
21:43.49 | JustinP | I said it's a binary |
21:43.57 | JustinP | a *binary* |
21:44.03 | zecke | JustinP: why is this in a lib* package? |
21:44.04 | JustinP | which is run by the thing which depends on it |
21:44.09 | JustinP | ask raster |
21:44.19 | JustinP | edje is both a lib and a compiler |
21:44.21 | zecke | JustinP: well libs are elf binaries too |
21:44.35 | emte | mmm |
21:44.41 | emte | edje_cc is the compiler |
21:44.48 | emte | but its not a lib as afar ai i know |
21:44.49 | JustinP | emte: yes |
21:44.57 | emte | fas as* |
21:44.57 | JustinP | emte: yes, edje is a lib |
21:45.07 | emte | edje is but nit edje_cc |
21:45.09 | emte | not* |
21:45.16 | JustinP | emte: any e stuff with themeing needs ot |
21:45.23 | JustinP | emte: and it's part of the same compile |
21:45.42 | emte | mmm |
21:46.01 | reenoo | JustinP: that doesn't mean you need to put it into the same package |
21:46.01 | emte | i am not sure if i agree that it "needs" it |
21:46.26 | emte | the themes need to be compiled to be used, but you dont need edje_cc to use the themes after they are compiled |
21:47.47 | *** join/#oe woglinde (i=woglinde@e178104198.adsl.alicedsl.de) |
21:47.51 | emte | the only one i think which breaks that rule is embryo |
21:48.31 | JustinP | fucking A, why isn't anyone listening |
21:48.42 | *** join/#oe mreimer_ (n=mreimer_@wl-wa.vpop.net) |
21:48.44 | JustinP | emte: I *KNOW* |
21:48.46 | emte | i'll have to remember to clarify that with raster otherwise i'll run into issues with my wm |
21:49.17 | JustinP | 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 |
21:49.50 | JustinP | zecke: since bitbake has some kind of issue with RDEPENDing on lib* packages |
21:49.56 | JustinP | it says there's no buildable rprovider |
21:50.08 | JustinP | but forcing the do_rootfs of the image works fine |
21:50.37 | reenoo | JustinP: sounds like you want to take that up with RP |
21:50.55 | emte | JustinP, how about cheating and just compiling it static and skiping the runtime dep? |
21:50.58 | JustinP | why's that? |
21:51.15 | JustinP | emte: WTF are you talking about? |
21:51.16 | JustinP | emte: I'm not talking about a library |
21:51.24 | JustinP | emte: the auto-depending on libs works fine |
21:51.32 | JustinP | emte: I'm talking about depending on edje_cc |
21:51.37 | JustinP | emte: please.... |
21:51.52 | emte | oh, i thought you ment the other direction |
21:52.08 | emte | edje_cc depending on libraries |
21:52.13 | JustinP | no |
21:52.18 | JustinP | that works fine, of course |
21:56.44 | emte | how does gcc handle the issue? |
21:57.09 | emte | or does it? |
21:58.31 | emte | off hand i'd think it would have the same problem with it's language support library files |
22:16.05 | *** join/#oe oris_wolfbane (n=oris@82-38-121-195.cable.ubr01.hali.blueyonder.co.uk) |
22:20.01 | JustinP | damn it |
22:20.06 | JustinP | why is it renaming this! |
22:20.21 | JustinP | s |
22:30.10 | zecke | JustinP: due debian.bbclass inherited in familiar.conf and oz.conf |
22:33.43 | JustinP | zecke: ok |
22:34.04 | JustinP | zecke: does debian.bbclass do the lib* stuff? is there a way to stop is for one PACKAGE entry? |
22:34.53 | zecke | JustinP: I'm not too sure if you can prevent it |
22:38.17 | JustinP | zecke: it's fine, I'll just add a new bbfile which makes the packages I need |
22:38.25 | JustinP | well, new bbfiles... |
23:03.26 | *** join/#oe woglinde_ (i=woglinde@e178119029.adsl.alicedsl.de) |
23:08.28 | *** join/#oe darkschneider (n=gab@213-140-6-96.ip.fastwebnet.it) |
23:14.52 | *** join/#oe emte (n=emte@64.180.41.158) |
23:17.46 | CoreDump|home | n8 |
23:18.03 | *** join/#oe poli (n=ca@200.168.30.125) |
23:20.00 | JustinP | gah |
23:20.09 | JustinP | CoreDump|home: some more commits coming... |
23:52.46 | *** join/#oe incinerator (n=incinera@82-41-24-164.cable.ubr04.edin.blueyonder.co.uk) |
23:53.38 | *** join/#oe _chronic (n=chronic@132.145.187.81.in-addr.arpa) |