00:02.05 | JustinP | ~lart statistics! |
00:03.05 | Luke-Jr | zwelch: or x86_64 |
00:03.29 | zwelch | Luke-Jr: yes, that is still a free variable |
00:03.53 | Luke-Jr | it wouldn't be the first time, either |
00:04.02 | zwelch | i believe you |
00:04.17 | Luke-Jr | the sqlite bug I was talking about earlier doesn't exist with x86_32, since its pointer size matches arm |
00:04.33 | CosmicPenguin | thats not x86_64s fault |
00:04.39 | Luke-Jr | nope |
00:04.44 | CosmicPenguin | if developers are supid enough to assume the size of unsigned long, then fuck em |
00:04.56 | Luke-Jr | lol |
00:05.07 | Luke-Jr | they #define pointer size based on sizeof(char *) during compile |
00:05.44 | Luke-Jr | which isn't a problem for x86_32 because it has the same size as arm |
00:06.06 | Luke-Jr | if arm was 64-bit, it'd be the reverse |
00:06.55 | Luke-Jr | sqlite comments *do* say cross-compilers should define the pointer size manually |
00:07.01 | Luke-Jr | but zecke wants to use autoconf |
00:07.04 | CosmicPenguin | so use it |
00:07.08 | CosmicPenguin | we use autoconf all the time |
00:07.18 | CosmicPenguin | why do you think an x86_64 site file exists? |
00:07.33 | Luke-Jr | heh, I can fix sqlite's problem manually |
00:07.43 | Luke-Jr | so glibmm is more of a priority to fix for me |
00:08.12 | Luke-Jr | I can't even tweak it to work manually |
00:12.58 | Luke-Jr | anyway, I'm not too surprised it works on x86_32 |
00:13.11 | Luke-Jr | that would explain why it might be using a non-portable libtool |
00:13.17 | Luke-Jr | (or non-cross-compile) |
00:17.32 | *** join/#oe thejapa (n=thejapa@200-232-209-21.dsl.telesp.net.br) |
00:19.12 | zwelch | hmmm, it appears that a recent update broke my configuration: http://rafb.net/paste/results/63u0EE54.html |
00:19.58 | zwelch | ... and my DISTRO="openzaurus-unstable", which still appears in the dev branch conf/distro/ directory. i'm not sure what's up. :/ |
00:26.52 | Luke-Jr | so how do I make libsigc++ and glibmm use OE's libtool? |
00:27.45 | CosmicPenguin | you know who I haven't seen in a while? pb_ |
00:27.50 | CosmicPenguin | is he hiding from OE these days? |
00:28.13 | zwelch | but i don't know why :/ |
00:28.16 | Luke-Jr | no ideas? :( |
00:28.21 | Kerwood_ | zwelch: well, I know one of mickeyl's last acts today was to rearrange the conf files in org.embedded.dev/conf |
00:28.40 | Kerwood_ | ~seen pb_ |
00:28.54 | ibot | pb_ <n=pb@cpc1-cmbg6-0-0-cust434.cmbg.cable.ntl.com> was last seen on IRC in channel #oe, 4d 3h 52m 56s ago, saying: 'hi kergoth, zecke'. |
00:28.54 | zwelch | Luke-Jr: first, you might figure out how libtool is being used |
00:28.58 | Luke-Jr | zwelch: ? |
00:29.02 | Kerwood_ | dayyum |
00:29.04 | Luke-Jr | dunno, what does libtool try to do? |
00:29.08 | zwelch | from there, it's probably a matter of running libtoolize or fixing the usage |
00:29.19 | zwelch | Luke-Jr: run 'info libtool' and read up |
00:29.26 | Luke-Jr | I don't have info |
00:29.49 | Luke-Jr | =p |
00:30.10 | zwelch | what, you want me to just say "RTFM" and leave it at that? ;) |
00:30.58 | Luke-Jr | sure =p |
00:31.08 | Luke-Jr | run libtoolize where? O.o |
00:31.13 | Luke-Jr | or should I use an eclass |
00:31.14 | Luke-Jr | ? |
00:31.15 | zwelch | to be more constructive, i would bet it's a problem with the glibmm makefiles |
00:31.23 | zwelch | which might be fixed in a newer version |
00:31.26 | Luke-Jr | I'm trying it on libsigc++ first |
00:31.32 | Luke-Jr | oh |
00:31.32 | Luke-Jr | ? |
00:31.55 | zwelch | well, koen asked me to look at those packages for that reason: to bump their versions to newer releases |
00:32.06 | zwelch | i will need to in order to get all of minisplat working |
00:32.29 | Luke-Jr | but why is it likely fixed in a new version? |
00:32.42 | Luke-Jr | either way, the .la from libsigc++ refer x86_64/lib |
00:33.36 | zwelch | i said "might" not "likely" |
00:34.04 | zwelch | but yeah, if it's a dep, then it may not show up until later either |
00:34.05 | Luke-Jr | true, you only bet on it being glibmm's makefiles not that it was fixed ;) |
00:34.35 | zwelch | actually, the problem might be a missing --with-stdlibc++ option in glibmm or something |
00:35.14 | zwelch | i had that problem with speex, where it was producing a .la with links to the native libstdc++, and it only showed up when trying to link against my audio codec package |
00:35.48 | Luke-Jr | well, how can I test if adding libtoolize helps? =p |
00:35.54 | zwelch | the fix was to tell the configure script where it really should be looking for the libraries (in ${STAGING_LIBDIR} and ${STAGING_INCDIR} |
00:36.44 | zwelch | well, you need to figure out exactly a) where the problem is originating, and b) what the problem actually is. libtoolize is a hypothetical solution for one possible problem |
00:37.23 | zwelch | Kerwood_: btw, i am aware of mickey's changes; this is why i brought the pastebin straight here ;) |
00:37.37 | zwelch | s/here/hear/ |
00:37.50 | Luke-Jr | zwelch: trial and error is probably the best I can do... :\ |
00:38.14 | Luke-Jr | and from what I can see, libtoolize on sigc++ seems most likely |
00:38.15 | zwelch | right, but have a strategy for isolating the fault |
00:38.24 | zwelch | well, that just replace the libtool files |
00:38.34 | Luke-Jr | grep shows x86_64/lib in sigc++'s .la's within staging/arm-linux |
00:38.45 | zwelch | if libstdc++ is somehow producing an .la that includes your native libraries, you need to tell it to knock it off |
00:38.50 | zwelch | libtoolize won't do that |
00:38.53 | zwelch | necessarily |
00:39.12 | zwelch | i.e. heck, it might, but there's no way to be sure at this point |
00:39.53 | zwelch | an easy way to hack the .bb? i dunno offhand; i'm still debugging some stuff like this :) |
00:43.05 | zwelch | Luke-Jr: incidentally, what are you trying to build that needs glibmm? |
00:45.04 | Luke-Jr | zwelch: GPE? |
00:45.18 | zwelch | Luke-Jr: oh, nothing big then... ;) |
00:45.21 | Luke-Jr | ... |
00:45.24 | zwelch | hehehe |
00:45.46 | Luke-Jr | this is looking to be only slightly easier to fix than my KDE BBs |
00:46.02 | zwelch | i really think we need to look at the latest versions |
00:46.11 | Luke-Jr | but that takes time and patience |
00:46.13 | Luke-Jr | =p |
00:46.33 | zwelch | i have both... in varying quantities, depending on the phase of the moon |
00:46.42 | Luke-Jr | I find my primary motivator to be my impatience sometimes |
00:46.45 | *** part/#oe Kerwood_ (n=Marshall@69-174-191-58.frdrmd.adelphia.net) |
00:46.51 | *** join/#oe Kerwood_ (n=Marshall@69-174-191-58.frdrmd.adelphia.net) |
00:46.59 | Luke-Jr | if I weren't impatient, I'd probably have just ignored the problem and figured it'll work in a month |
00:47.11 | Luke-Jr | instead of trying to figure it out |
00:48.08 | Luke-Jr | ... |
00:48.15 | zwelch | in which case, the bug is not really a bug.... except the output trace is sort of annoying |
00:48.16 | Luke-Jr | mickey broke it? |
00:48.31 | zwelch | by my new found reasoning, no |
00:48.49 | zwelch | and sorry, i mistyped, i meant to say openzaurus-unstable |
00:49.01 | Luke-Jr | that's what I'm trying to build |
00:49.25 | zwelch | my local.conf had that set as its DISTRO, and my most recent mt pull gave me the pastebin above |
00:50.03 | zwelch | now, reading the full error and considering things, i can see the rational to force users to manually invervene before building an "unstable" tree |
00:50.28 | zwelch | most folks probably should be using the stable branch |
00:51.13 | zwelch | since i need to bump a lot of packages, i don't think that's my best path and have selected dev and unstable |
00:52.12 | zwelch | so, you can see this as a bug, if you think anyone should be able to build the unstable branch without having to think about it first :) |
00:53.27 | Luke-Jr | ... |
00:55.56 | *** join/#oe csmanx (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
00:56.07 | *** join/#oe W8TVI (n=me@166.166.11.74) |
00:57.03 | zwelch | so, here's a silly feature request: how about versioning the tarballs from svn repos by their revision, rather than by date? then, instead of getting a new tarball each day, we only get one when the repo actually changed that day |
00:57.12 | zwelch | is that silly, or what? |
00:57.53 | zwelch | hmmm. +ly? |
00:58.15 | thejapa | isn't that a cvs feature called tags? hehe |
00:58.17 | Kerwood_ | zwelch: here are the comments from the relevant patch: |
00:58.20 | Kerwood_ | (11:12:26 AM) CIA-9: conf/distro cleanup. conf/distro should only contain files that are ok to be directly included |
00:58.20 | Kerwood_ | (11:12:26 AM) CIA-9: by means of setting DISTRO. conf/distro/include should contain those which doesn't. |
00:59.10 | zwelch | yes, but openzaurus-unstable is still in conf/distro/ directly |
00:59.39 | Kerwood_ | zwelch: hey, I just report the news... |
00:59.46 | zwelch | the difference appears to be that it doesn't set its DISTRO, letting it be set by the include/openzaurus.inc |
00:59.57 | zwelch | since they don't match, the configuration is presumed insane |
01:00.12 | zwelch | Kerwood_: likewise, i'm just calling it like i see it :) |
01:01.19 | zwelch | after following its directions, everything started working again, but it reflects the fact that you need to be prepared to fix everything yourself ;) |
01:02.05 | Kerwood_ | yup |
01:02.41 | zwelch | overall, he probably did exactly the right thing, given the circumstances |
01:10.02 | zwelch | thejapa: btw, afaik, cvs doesn't have the equivalent revision support; timestamps are the only way to get each "changeset" in the same manner |
01:11.08 | zwelch | in effect, the svn repo revision is another monotonically increasing package version, and while bb has support for specifying a specific revision this way, i don't see a way to say "the latest HEAD" |
01:11.31 | zwelch | or, maybe it has it and i just need to try it ;) |
01:11.58 | thejapa | zwelch: sorry, i'm actually very ignorant on cvs and other source control apps :) |
01:12.02 | zwelch | effectively, it's just a little extra logic to say "if asking for HEAD, get it, then convert that to an actual rev" |
01:12.30 | thejapa | i was with cvs on my head because i'm just trying my first steps in it. :) |
01:12.50 | zwelch | my problem is that i am ignorant of bitbake, so i'm not sure exactly how easy this would really be |
01:13.10 | zwelch | ....because it involves very late binding of the package revision... i.e. after fetch |
01:13.52 | zwelch | now after thinking about it, i can see why it's not trivial and probably not worth implementing :) |
01:14.14 | zwelch | see, i told you it was a silly request |
01:14.48 | thejapa | yeah, i dumbily(sp?) agree |
01:15.12 | thejapa | that's double dumb I guess |
01:16.52 | thejapa | dumb because i don't have the bitbake knowledge to understand the difficulty and double dumb because i don't know how to write dumbly/dumbilly/dumbily :) |
01:17.12 | thejapa | triple dumb now |
01:25.59 | *** join/#oe ts____gin (n=gints@62.84.15.211) |
01:27.22 | zwelch | nifty. i just fixed a bug in pkgconfig.bbclass |
01:32.35 | zwelch | fwiw: http://bugs.openembedded.org/show_bug.cgi?id=1174 |
01:41.37 | zwelch | so, i have a question about the notes in the manual... when it says "this only works with .bb and .bbclass files", one can presume the same is true for files "include"d or "require"d by such files? |
01:42.02 | zwelch | e.g. in .inc files required by .bbfiles |
01:45.08 | Luke-Jr | libtoolize doesn't work on libsigc++ :( |
01:45.15 | Luke-Jr | its configure script appears to undo it |
01:46.05 | *** join/#oe dijenerate (n=dijenera@72.22.136.181) |
01:49.30 | zwelch | the autotools.bbclass runs autoreconf during do_configure |
01:52.19 | *** join/#oe wrobbie (n=rob@cm7.sigma181.maxonline.com.sg) |
01:54.45 | *** join/#oe hvontres|home (n=henry@adsl-75-28-3-182.dsl.sndg02.sbcglobal.net) |
01:56.36 | *** join/#oe Laibsc1 (n=Laibsch@V30c7.v.pppool.de) |
01:56.59 | zwelch | Luke-Jr: good luck. i'll be back in several hours |
01:59.58 | hvontres|home | CoreDump|home: morning :) |
02:00.57 | *** join/#oe crigo (n=crigo@no.e-volution.ro) |
02:08.38 | *** join/#oe punk-ass (n=user@ptbynynas01pool0-a171.ptbyny.tds.net) |
02:30.03 | kergoth | damnit, why do all the other core bitbake devs have to be in europe :P |
02:33.31 | joshin | because we only let minimum wage employees come to the USA |
02:33.57 | kergoth | hehe |
02:36.14 | Luke-Jr | zwelch: indeed, but autoreconf doesn't help it |
02:36.50 | Luke-Jr | zwelch: I moved libtoolize to post-configure, so next time it tries building we'll see |
02:37.05 | Luke-Jr | unfortunately, my bitbake has once again decided it doesn't need glibmm =p |
02:37.22 | Luke-Jr | or fortunately for me if it works, I guess =p |
02:37.53 | kergoth | it should be libtoolizing automatically, autoreconf calls it out |
02:38.01 | Luke-Jr | kergoth: the configure script undoes it |
02:38.20 | Luke-Jr | or seems to, from my limited knowledge of this stuff |
02:38.44 | Luke-Jr | the 'libtool' program in the work directory is different from the normal OE 'libtool' programs |
02:40.28 | hvontres|home | kergoth: only about 4 more hours till daylight over there :) |
02:40.43 | Luke-Jr | checking if libtool supports shared libraries... yes |
02:40.43 | Luke-Jr | config.status: executing libtool commands |
02:40.49 | Luke-Jr | that part is probably related |
02:44.56 | kergoth | Luke-Jr: libtoolize should be overwriting the ltmain.sh in the source tree, which configure uses to generate the local libtool. |
02:45.07 | kergoth | hvontres|home: :) |
02:47.52 | Luke-Jr | kergoth: well, the .la is ending up with staging/x86_64-linux (host) paths... |
02:48.01 | Luke-Jr | kergoth: you'd know better than I |
02:48.35 | kergoth | dont use the term 'host' |
02:48.37 | kergoth | its ambiguous |
02:48.44 | Luke-Jr | forcing libtoolize *after* configure doesn't leave a libtool prog |
02:48.47 | Luke-Jr | build |
02:48.53 | kergoth | okay, weird |
02:49.25 | Luke-Jr | well, it makes sense if configure creates it from ltmain |
02:49.34 | Luke-Jr | I don't know about getting a good .la tho |
02:50.51 | hvontres|home | ~seen JustinP |
02:51.39 | ibot | justinp <i=papercra@c-67-174-226-161.hsd1.ca.comcast.net> was last seen on IRC in channel #oe, 2h 49m 34s ago, saying: '~lart statistics!'. |
03:28.24 | *** join/#oe noclouds (n=mhfan@60.166.48.174) |
03:40.43 | JustinP | hvontres|home: ? |
03:40.49 | JustinP | hvontres|home: errr...pong |
03:41.55 | hvontres|home | JustinP: hi. I am installing the images right now... just wanted to see if you were still around |
03:43.29 | JustinP | hvontres|home: cleaning, so in and out |
05:44.53 | *** join/#oe mhfan (n=mhfan@60.166.51.172) |
06:02.14 | *** join/#oe JaMae (n=martin@njama.mk.cvut.cz) |
06:08.27 | *** join/#oe zap (n=zap@85.249.170.16) |
06:17.25 | *** join/#oe |BundaBRG|z (n=|BundaBR@CPE-147-10-235-152.wa.bigpond.net.au) |
06:21.13 | *** join/#oe |BundaBRG|z (n=brendan@CPE-147-10-235-152.wa.bigpond.net.au) |
06:23.39 | |BundaBRG|z | OK another quick question. (new at OE). I've created a .bb file for 'gtimer'. It compiles fine. Im using org.openembedded.dev. Hower its dependencies are either newer or are all 1.0.1 whcih will overwrite a lot of libraries on my OZ3.4.5.1. Am I using the wrong dist? |
06:25.21 | *** join/#oe katossi (n=guillerm@dslb-084-061-098-062.pools.arcor-ip.net) |
06:27.04 | *** join/#oe |BundaBRG|z (n=brendan@CPE-147-10-235-152.wa.bigpond.net.au) |
06:29.04 | *** join/#oe johnX (n=john@c-71-231-59-137.hsd1.wa.comcast.net) |
06:29.23 | JustinP | <PROTECTED> |
06:30.23 | |BundaBRG|z | Thanks. I thought as much. |
06:47.31 | *** join/#oe dkey (n=dkey@192-186-stud-adsl.wu-wien.ac.at) |
07:07.24 | *** join/#oe ar_ (n=ar@port-ip-213-211-250-51.reverse.mdcc-fun.de) |
07:10.29 | *** join/#oe awelux (n=awelux__@dslb-084-058-163-207.pools.arcor-ip.net) |
07:25.38 | *** join/#oe mithro (n=tim@ppp246-117.static.internode.on.net) |
07:30.14 | *** join/#oe goxboxlive (n=goxboxli@ti500710a080-7302.bb.online.no) |
07:52.22 | RP | morning all |
07:52.36 | hvontres|home | morning RP |
07:52.48 | *** join/#oe shiyee (n=Shiyee@0x535d64c1.abnxx4.adsl-dhcp.tele.dk) |
07:53.21 | hvontres|home | RP: have you heard of anybody using image files with altboot on 2.6.17? |
07:53.51 | RP | hvontres|home: no, but I don't see why 2.6.17 would make a difference |
07:54.31 | hvontres|home | RP: I am trying to figure out why I can boot from my sd card but not from a loop file on the same card. |
07:55.30 | hvontres|home | I'll try to catch CoreDump later.. |
07:56.28 | JustinP | hvontres|home: maybe loopback support is missing...? perhaps some e2fstools missing? |
07:56.34 | RP | hvontres|home: I don't really use altboot so he'd be the better person to talk to |
07:57.19 | JustinP | never booted from an image on SD, though |
07:57.45 | hvontres|home | JustinP: I can mount the loopback file, but it will hang during boot. |
07:58.18 | hvontres|home | For now I made four partitions on my 1GB card.. 1 common, 1 for gpe, 1 for e and 1 for opie..:) |
07:58.25 | JustinP | hang where? |
07:58.38 | JustinP | I assume they're my images.... |
07:58.49 | JustinP | they *could* have 2.4 thing in them....although they shouldn't |
07:58.58 | JustinP | but if a partition works.... |
07:59.36 | hvontres|home | JustinP: depends. your gpe image hangs on loading the keymap, e hangs during udev and my opie image during portamap |
08:00.22 | hvontres|home | JustinP: e image is going through first boot now... calibration just came up :) |
08:01.12 | JustinP | yeah, takes a while |
08:01.24 | JustinP | I've been meaning to use qemu to do the menu generation |
08:01.34 | JustinP | but have had so little testing in general that.... |
08:01.53 | hvontres|home | JustinP: The touchscreen cal seems to be stuck in an endless loop :( |
08:02.41 | JustinP | that's not a good sign... |
08:02.42 | JustinP | ugh |
08:02.53 | JustinP | I don't know why some people have problems with entrance not working |
08:03.13 | JustinP | Fn-Alt-Backspace to kill X |
08:03.44 | JustinP | well...not sure what it would be on poodle |
08:03.58 | JustinP | ~poodle |
08:04.00 | ibot | extra, extra, read all about it, poodle is sharp sl-b500/5600, or a dog |
08:04.10 | JustinP | ah....that one.... |
08:04.18 | hvontres|home | RP: where did you guys put the alt key on poodle? |
08:04.38 | JustinP | you may have problems with screen size. AFAIK e was never tested on a 320x240 screen |
08:04.52 | RP | hvontres|home: I don't know - I didn't write the keymap |
08:05.00 | hvontres|home | heh, it is now :) |
08:05.03 | JustinP | you could also use a USB connection to SSH in and kill Xfbdev |
08:05.25 | JustinP | or wireless of whatever....not that you can set up wireless without some input |
08:05.44 | *** join/#oe TMM1 (n=aman@c-65-96-169-40.hsd1.ma.comcast.net) |
08:05.52 | hvontres|home | let me check the wiki... |
08:06.54 | JustinP | 56 or 67 perhaps? |
08:07.30 | JustinP | (not that I know what ley that is) |
08:08.12 | JustinP | Address button |
08:08.29 | JustinP | I think |
08:09.01 | JustinP | keycode 56 = SAlt # Address |
08:09.19 | hvontres|home | tried that... no dice... |
08:09.41 | hvontres|home | hmm, and I need a console to set up usb...:( |
08:10.51 | JustinP | the default won't work? |
08:11.24 | hvontres|home | need to load g_ether by hand... |
08:12.17 | hvontres|home | still need to fix that |
08:12.41 | hvontres|home | thanks for the image.. will need to work on that some more... later. |
08:12.49 | hvontres|home | Time for bed |
08:13.50 | JustinP | you can always boot to something else and edit its files ;-) |
08:13.52 | JustinP | sleep well |
08:15.15 | hvontres|home | I'll give gpe a shot now..:) |
08:17.40 | hvontres|home | CoreDump|afk: have you tested loop images off sd on your poodle yet? |
08:22.53 | *** join/#oe tkp (n=tom@81-179-24-207.dsl.pipex.com) |
08:29.49 | *** join/#oe Mardy (n=mardy@adsl-239-73.38-151.net24.it) |
08:35.12 | *** join/#oe RickSeymour (n=rick@user-83-245-80-233.euro1net.com) |
08:41.04 | RickSeymour | When running nsqld (one of the daemons for opensync) i get the error "socket: Address family not supported by protocol", any ideas? (Running Poodle OZ 3.5.4/GPE) |
08:51.36 | *** join/#oe dijenerate (n=dijenera@72.22.136.181) |
08:52.44 | *** join/#oe tmbinc (i=XXX@e176163233.adsl.alicedsl.de) |
08:56.24 | *** join/#oe Cwiiis (n=cwiiis@82-43-42-18.cable.ubr02.croy.blueyonder.co.uk) |
09:02.05 | *** join/#oe pH5 (n=ph5@p54866C0C.dip.t-dialin.net) |
09:07.24 | *** join/#oe maja (n=maja@host60-20.pool8261.interbusiness.it) |
09:09.25 | *** join/#oe v8jlene (n=lenehan@nynaeve.twibble.org) |
09:22.39 | *** join/#oe TheCan (n=thecan@dslb-084-056-136-162.pools.arcor-ip.net) |
09:23.30 | *** join/#oe polyonymous_ (i=hacker@pD953949D.dip0.t-ipconnect.de) |
09:24.10 | *** join/#oe YoG (n=zevele@bzq-88-155-190-220.red.bezeqint.net) |
09:27.16 | RickSeymour | hi there... wheres our buzgilla? |
09:27.19 | RickSeymour | bugzilla |
09:31.42 | JustinP | RickSeymour: I suspect it's trying to run in ipv6 mode |
09:31.56 | JustinP | RickSeymour: bugs.openembedded.org |
09:34.09 | CIA-9 | 03mickeyl * r549 10bitbake/lib/bb/msg.py: msg needs to import sys, it calls it |
09:35.53 | JustinP | whee, bitbake commits |
09:37.08 | RP | yay :) |
09:42.14 | *** join/#oe |BundaBRG|z (n=brendan@CPE-147-10-235-152.wa.bigpond.net.au) |
09:45.01 | *** join/#oe goxboxlive_ (n=goxboxli@ti500710a080-7302.bb.online.no) |
09:45.11 | |BundaBRG|z | mmm, ok new question. org.embedded.dev compiles gtk+-1.2 fine but org.embedded.oz354x does not (configure error says no X libs installed, yet they seem to be in the staging dir). Ive diffed the two bb files and the only diff is dev RDEPENDS on libxext and oz354x RDEPENDS on xext. Is there something Im missing? ta |
09:47.54 | RP | |BundaBRG|z: The xlibs were reworked in .dev and some were renamed. That's unlikely to be the real problem |
09:49.26 | |BundaBRG|z | Yeah, xext compiles fine. |
09:57.01 | CIA-9 | 03mickeyl 07org.oe.dev * r0f90c48c... 10/classes/sanity.bbclass: |
09:57.01 | CIA-9 | sanity.bbclass: relax the DISTRO check a bit, taking into account that some DISTRO configurations |
09:57.01 | CIA-9 | override DISTRO before sanity.bbclass gets a chance to see it. By definition, in this case $RENAMED_DISTRO |
09:57.02 | CIA-9 | needs to be present in distro/include/ though, so we have a second chance for the test to succeed. |
10:12.52 | *** join/#oe exastra (n=go@c-24-21-152-246.hsd1.or.comcast.net) |
10:13.17 | Laibsch | I see, that is why my OE was acting up again. And I thought it was me, checking DISTRO over and over again. |
10:15.33 | mickey|zzZZzz | sorry |
10:18.13 | Laibsch | np |
10:18.36 | Laibsch | a few things will still not compile anyhow. |
10:18.45 | Laibsch | poboxserver among them. |
10:19.01 | mickey|breakfast | how does it bail out? |
10:22.07 | *** join/#oe exastra (n=go@c-24-21-152-246.hsd1.or.comcast.net) |
10:50.20 | *** join/#oe incinerator (n=sabine@82-41-24-164.cable.ubr04.edin.blueyonder.co.uk) |
11:08.52 | *** join/#oe Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) |
11:10.53 | *** join/#oe woglinde (i=woglinde@e178089191.adsl.alicedsl.de) |
11:22.04 | CoreDump|home | morning |
11:25.06 | woglinde | what? |
11:25.20 | woglinde | there are now security patches anymore |
11:25.24 | woglinde | no |
11:25.30 | CoreDump|home | hehe |
11:25.56 | CoreDump|home | the poor P$something 233MHz doesn't care about that ;) |
11:26.11 | woglinde | linux |
11:26.30 | CoreDump|home | I can't :\ |
11:26.40 | woglinde | why? |
11:26.53 | CoreDump|home | I need Siemens Step5 software (beside other windows/DOS stuff) |
11:27.08 | woglinde | hm |
11:27.53 | CoreDump|home | I used to have it dual-boot between debian and win98, I guess I'll set that up again (had a total HDD failure / dataloss) |
11:28.50 | woglinde | http://linuxdevices.com/articles/AT8243331060.html |
11:28.55 | woglinde | I need one |
11:28.57 | woglinde | I guess |
11:29.24 | CoreDump|home | sweet |
11:29.58 | woglinde | damn it that I am not a friend of harald |
11:30.41 | CoreDump|home | who's harald? |
11:30.47 | woglinde | laforge |
11:31.02 | woglinde | the openexzs guy |
11:32.15 | CoreDump|home | ahh |
11:32.30 | woglinde | he is in shanghai right now |
11:32.37 | woglinde | and bought this phone already |
11:32.46 | CoreDump|home | well, a (fully working!) mobile running (s hackable) linux would be indeed nice |
11:33.13 | woglinde | http://gnumonks.org/~laforge/weblog/2006/07/10/#20060710-rokr_e2 |
12:11.13 | |BundaBRG|z | bah still cant work this one out ;) org.openembedded.dev compiles gtk+1.2 fine but oz354x doesn't, it complains during the configure phase that there are no X libraries or includes available (though Im sure I see them in staging). Any ideas? |
12:14.27 | woglinde | maybee the searching directories are wrong in oz branch |
12:24.15 | CIA-9 | 03rpurdie 07org.oe.dev * r096aede5... 10/packages/linux/linux-openzaurus_2.6.17+git.bb: linux-oz-2.6.17+git: Update to latest git, refresh epalloc patch and add a fix for the mainline mtd breakage of the sharpsl mtd driver. |
12:29.26 | *** join/#oe lmanul (n=manu@dan75-4-82-239-58-38.fbx.proxad.net) |
12:36.35 | |BundaBRG|z | woglinde: how do i set the search dirs? The configure script is definalty pointing at the staging area for oz354x (via -L and -I) |
12:39.30 | *** join/#oe jkp (n=jkp@growl/jkp) |
12:42.22 | woglinde | bunda what does the config.log says? |
12:47.27 | |BundaBRG|z | Normally I can read the config.log files and know what went wrong but I have to admit this one has me a bit confused. The 92kb config.log can be seen at http://www.worldguard.com.au/config.log |
12:49.21 | woglinde | conftest.c:54:27: X11/Intrinsic.h: No such file or directory |
12:49.33 | *** join/#oe offroadgeek (n=offroadg@pdpc/supporter/sustaining/offroadgeek) |
12:50.42 | woglinde | so you have to check if Intrinsic.h is in the X include dir |
12:55.55 | *** join/#oe magnet_ (n=magnet@lns-bzn-28-82-250-152-111.adsl.proxad.net) |
12:56.28 | |BundaBRG|z | thanks, ill have a look |
13:06.23 | |BundaBRG|z | Thanks woglinde. I wasnt looking back far enough. Intrinsic.h is part of libxt. And according to RP dev has had rework on these libs thus possibly fixing the problem. Ive just added xt as a dep which I hope fixes my prob. |
13:06.44 | woglinde | no prob :) |
13:09.57 | |BundaBRG|z | whoo compiles :) |
13:11.28 | *** join/#oe m4gnet (n=magnet@lns-bzn-28-82-250-152-111.adsl.proxad.net) |
13:13.42 | *** join/#oe drw (n=drw@c-67-173-199-53.hsd1.tx.comcast.net) |
13:37.25 | *** join/#oe Ironnads_ (n=Ironnads@host86-135-183-55.range86-135.btcentralplus.com) |
13:38.00 | *** join/#oe nts____gi (n=gints@62.84.15.211) |
13:45.05 | *** join/#oe Greg2 (n=greg@pub35.hunt4.nfis.com) |
13:45.14 | Greg2 | hello everyone |
13:47.46 | *** join/#oe joshin (i=josh@VDSL-130-13-143-17.PHNX.QWEST.NET) |
13:56.12 | Greg2 | ~seen CoreDump|home |
13:56.21 | ibot | coredump|home <n=mhentges@hentges.net> was last seen on IRC in channel #oe, 2h 23m 35s ago, saying: 'well, a (fully working!) mobile running (s hackable) linux would be indeed nice'. |
13:56.53 | CoreDump|home | pinging me usually works fine when I'm around;) |
13:57.17 | Greg2 | CoreDump|home ok |
13:58.02 | Greg2 | CoreDump|home: have you built a 2.6.17 opie-image in oz354x with a working ts |
13:58.19 | Greg2 | poodle |
14:00.25 | CoreDump|home | Greg2: yeah, I've pushed a fix for poodle ts on 2.6 a few days ago |
14:00.58 | Greg2 | CoreDump|home: i'm having trouble with my poodle 2.6.17 kernel opie-image... no working touchscreen :-( |
14:01.10 | CoreDump|home | update your meta data |
14:01.25 | Greg2 | i did yesterday |
14:01.36 | CoreDump|home | and you rebuilt tslib? |
14:02.10 | Greg2 | i built an image yesterday |
14:02.38 | *** join/#oe EvilDevil_ (n=miau@p54A6F152.dip.t-dialin.net) |
14:03.20 | CoreDump|home | which PR of tslib is installed? r39 or r40? |
14:03.43 | Greg2 | i'll check |
14:03.55 | CoreDump|home | http://www.openembedded.org/viewmtn/getdiff.py?id1=0c38f65e94162e11d2eaf4f1d6484eb28b7b43a7&id2=6085cf4d41b528aee7379c2ef6b24e17a490e133 <- the fix |
14:05.24 | tkp | I'm trying to install a package that needs klibc to build... |
14:06.01 | tkp | I have installed the klibc package, yet klibc is not found in the path, so the build fails |
14:06.51 | tkp | the klibc stufff got built into to tmp/staging/i586-oe-linux/klibc/lib/klibc |
14:07.03 | Greg2 | r39 |
14:07.10 | tkp | what's the best way to add this to my PATH in bitbake fassion? |
14:08.14 | CoreDump|home | Greg2: your meta-data is not up-to-date then as OE would have built -r40 automatically |
14:09.11 | tkp | hmm.. the klibc package doesn't even seem to have installed a klibc binary |
14:10.05 | Greg2 | CoreDump|home: hmm, it picked up you keyboard patch |
14:10.41 | Greg2 | i'll do a pull |
14:16.17 | Greg2 | bytes in | bytes out | certs in | revs in | revs written |
14:16.17 | Greg2 | monotone: 196 | 1,125 | 0 | 0 | 0 |
14:17.28 | Greg2 | CoreDump|home: it's up to date |
14:17.37 | tkp | what does @oe_filter_out do? |
14:17.43 | tkp | as in TARGET_CFLAGS := "${@oe_filter_out('-I\S+', '${TARGET_CFLAGS}', d)} -I${STAGING_KERNEL_DIR}/include" |
14:18.19 | CoreDump|home | Greg2: do "mt diff tslib" |
14:19.12 | Laibsch | ~hail mickey|breakfast poboxserver does indeed compile now. |
14:19.14 | ibot | ACTION bows down to mickey|breakfast poboxserver does indeed compile now. and chants, "I'M NOT WORTHY!!" |
14:19.24 | Laibsch | ;-) |
14:20.12 | Greg2 | sh*t, someones at my door... bbiab |
14:31.32 | *** join/#oe Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) |
14:34.36 | CoreDump|home | RP: youa round? I'm getting major distortions with poodles alsa driver. |
14:36.34 | Greg2 | CoreDump|home: i'll have to get back to this later, i have visitors now :-/ |
14:36.38 | Greg2 | CoreDump|home: thanks for your help |
14:37.20 | Greg2 | bbl |
14:37.30 | CoreDump|home | Greg2: np, have fun |
14:37.48 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
14:42.23 | RP | CoreDump|home: yes |
14:42.43 | tkp | how can I completely override the cflags for oe_runmake? |
14:43.16 | CoreDump|home | IIRC you were mentioning that poodles sound would work now. Well it makes "noise" =) |
14:43.33 | RP | CoreDump|home: It should work fine - at least it did for me |
14:43.37 | RP | CoreDump|home: Which application? |
14:44.27 | CoreDump|home | I have a special sound file in "raw" format which can be played w/ "cat $file > /dev/dsp". That plays the sound once, then comes static noise |
14:45.10 | RP | So its not stopping playback? |
14:45.30 | RP | What happens if you then play a file with something like madplay or aplay? |
14:45.41 | CoreDump|home | also playing with the "speaker" setting in alsamixer kills any sound output. Only rebooting helps at this point |
14:45.42 | *** join/#oe chouimat|ibook (n=dieu@r2351064.cidc.net) |
14:45.47 | CoreDump|home | RP: will try |
14:46.08 | RP | CoreDump|home: The speaker setting in alsamixer is problematic at best |
14:46.18 | CoreDump|home | =) |
14:46.43 | RP | CoreDump|home: Does the same thing come from the headphones and does the volume control change the volume level of the static? |
14:46.44 | CoreDump|home | can it be disabled? That's going to confuse users a lot i guess heh |
14:47.19 | RP | CoreDump|home: We need to fix ASoC - its a known bug which XorA/lrg are looking into as it also appears on corgi |
14:47.21 | CoreDump|home | didn't try headphones yet. Vol +/- changes noise output. The noise doesn't loop. |
14:47.40 | CoreDump|home | kinda hard to explain hmm |
14:47.54 | CoreDump|home | I'll try aplay or something like that |
14:48.08 | RP | It sounds like its locked playing static. This would be bug in ASoC |
14:48.16 | CoreDump|home | (but the cat trick works nicely on akita and my notebook ;)) |
14:48.17 | *** join/#oe dkey| (n=dkey@192-186-stud-adsl.wu-wien.ac.at) |
14:48.31 | RP | Yes, it should stop, I don't deny that :) |
14:48.54 | CoreDump|home | RP: nah, it doesn't lock up. It plays the sound once, ending the play w/ static. Any further attempt results in only static |
14:49.22 | RP | CoreDump|home: Does a suspend/resume let you play the sound again? |
14:49.31 | RP | I'd test corgi if I hadn't just trashed its mtd :-( |
14:49.50 | CoreDump|home | poodle doesn't like suspend w/ root on NFS ;) |
14:49.55 | CoreDump|home | RP: ouch |
14:50.02 | RP | jffs2 is now broken in mainline kernels :-( |
14:50.40 | *** join/#oe ar_ (n=ar@port-ip-213-211-250-51.reverse.mdcc-fun.de) |
14:50.42 | RP | I fixed the sharpsl NAND driver they also broke, only to have it trash all the data on the device :-( |
14:51.18 | CoreDump|home | argh |
14:51.42 | CoreDump|home | so .17 is the last usable kernel currently? |
14:51.58 | tkp | I have tried setting CPPFLAGS, BUILD_LDFLAGS, EXTRA_OEMAKE, CFLAGS LDFLAGS, & TARGET_CFLAGS all to "" and still oe_runmake has reference to all sorts of include directories |
14:52.05 | tkp | where are they comming from? |
14:52.27 | CoreDump|home | RP: same problem w/ aplay. a .wav file is played correctly, followed by static |
14:52.37 | RP | CoreDump|home: correct, I'd not recommend the git ones now |
14:52.41 | *** join/#oe aquadran (n=pablo@scummvm/undead/aquadran) |
14:52.44 | RP | CoreDump|home: Which toolchain is this? |
14:53.08 | CoreDump|home | a (almost) clean .oz built from yesterday |
14:53.23 | RP | so gcc 3.4.4? |
14:53.43 | CoreDump|home | gcc-cross-locale-be_3.4.4-r3_armv5te.ipk |
14:53.46 | CoreDump|home | yep |
14:54.33 | RP | there goes that theory :) |
14:54.49 | CoreDump|home | hehe |
14:54.55 | CoreDump|home | let me search my headset |
14:56.48 | CoreDump|home | ouch |
14:56.57 | CoreDump|home | same static on the headset =) |
14:57.33 | *** join/#oe mithro (n=tim@ppp246-117.static.internode.on.net) |
14:57.56 | RP | Do you want to try my kernel? I'd like to work out why yours does this and mine doesn't... |
14:58.10 | CoreDump|home | sure |
14:58.21 | *** join/#oe ar_ (n=ar@port-ip-213-211-250-51.reverse.mdcc-fun.de) |
14:59.06 | RP | Thankfully I still have it :) |
14:59.34 | RP | http://www.rpsys.net/openzaurus/temp/poodle/ |
14:59.43 | RP | I only have the modules.tgz, not the ipks I'm afraid |
15:00.11 | CoreDump|home | np |
15:06.31 | *** join/#oe koen (n=koen@dominion.kabel.utwente.nl) |
15:06.59 | *** join/#oe Kerwood (n=Kerwood@69-174-191-58.frdrmd.adelphia.net) |
15:07.17 | koen | good morning all |
15:07.20 | CoreDump|home | kexec'ed your kerneö |
15:07.25 | CoreDump|home | morning koen |
15:07.30 | *** join/#oe Kerwood_ (n=Marshall@69-174-191-58.frdrmd.adelphia.net) |
15:08.10 | *** part/#oe Kerwood (n=Kerwood@69-174-191-58.frdrmd.adelphia.net) |
15:08.48 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
15:12.43 | *** join/#oe TheCan (n=thecan@dslb-084-056-136-162.pools.arcor-ip.net) |
15:13.13 | CoreDump|home | RP: same problem w/ your kernel and modules :( |
15:14.31 | RP | CoreDump|home: Not good :-( |
15:17.20 | RP | This suggests hardware differences which I don't like the sound of (no pun intended) |
15:17.52 | CoreDump|home | hehe |
15:17.59 | CoreDump|home | I got a pxa255 here |
15:18.05 | CoreDump|home | if that matters *shrug* |
15:18.27 | Luke-Jr | how can I tell for sure if a libtool is from OE? |
15:18.32 | RP | I wonder if mine is a 250... |
15:18.54 | CoreDump|home | Processor : XScale-PXA255 rev 6 (v5l) |
15:18.59 | RP | Mine is a 250 |
15:19.03 | CoreDump|home | heh |
15:19.50 | CoreDump|home | ok, the thing is: The sound is played correctly but after the file is played, static is produced for ~2s |
15:19.51 | RP | If anything, I'd have said this would work the other way around... |
15:20.01 | RP | Just 2s? |
15:20.06 | CoreDump|home | yeah |
15:20.21 | CoreDump|home | ok, more like 3... |
15:20.26 | RP | That's DAPM holding the sound chip open before shuttdown the power to it |
15:20.54 | CoreDump|home | there is no trace of static in the sound itself when it is beeing played |
15:21.19 | RP | Right, so something in the shutdown is screwing up... |
15:21.52 | RP | and things don't play right again, even after waiting until after the 3seconds before playing again? |
15:22.04 | CoreDump|home | they do play right |
15:22.12 | CoreDump|home | but always ended w/ static |
15:22.43 | Luke-Jr | are you running cat /dev/urandom>/dev/dsp after? |
15:22.46 | Luke-Jr | =p |
15:22.50 | RP | ah, ok. That's an important difference :) |
15:23.12 | CoreDump|home | heh |
15:23.38 | RP | CoreDump|home: so replaying something whilst its making static noise just continues with static? |
15:24.37 | CoreDump|home | nope, in that case the static ends and the sound is played correctly (and ended w/ static again) |
15:26.09 | Luke-Jr | perhaps the chip is turned off, but the speaker isn't? |
15:28.27 | RP | CoreDump|home: I'll mention this to Liam and see what he says - its in his code rather than mine :) |
15:28.36 | CoreDump|home | RP: thanks! |
15:29.15 | Luke-Jr | CoreDump|home: anything in dmesg? |
15:29.59 | CoreDump|home | soc: DAI[0:0] failed to match clock masters |
15:29.59 | CoreDump|home | soc: DAI[0:1] failed to match rate |
15:29.59 | CoreDump|home | soc: DAI[0:2] failed to match rate |
15:29.59 | CoreDump|home | s |
15:29.59 | RP | CoreDump|home: I don't think its anything major - the codec might just need to be a bit heavier handed when changing DPM states |
15:30.20 | CoreDump|home | soc: DAI[14:6] failed to match rate |
15:30.20 | CoreDump|home | soc: DAI[15:0] Match OK |
15:30.20 | CoreDump|home | s |
15:30.27 | CoreDump|home | lots of these entries |
15:30.28 | RP | Its a debug kernel so you'll see a lot of general info like that |
15:30.34 | *** join/#oe katossi_ (n=guillerm@dslb-084-061-014-232.pools.arcor-ip.net) |
15:30.35 | *** join/#oe joshin (i=josh@VDSL-130-13-143-17.PHNX.QWEST.NET) |
15:30.38 | RP | Its just searching for matching bitrates |
15:30.56 | RP | (which we had issues with but have resolved - need to turn off the debugging now) |
15:31.01 | NAbyss | Is glibc broken in .dev? |
15:32.23 | koen | NAbyss: glibc 2.4 compiles fine over here |
15:33.49 | NAbyss | koen: Hmm.. looks like oz-unstable's pulling in glibc-2.3.5.. time to do a bit of digging. |
15:34.35 | Luke-Jr | shouldn't "inherit autotools" run libtoolize? |
15:34.42 | RP | CoreDump|home: After playback, do you see a message about WM8731 muting when the static starts, then a message about D3 WM8731 just as the static stops? |
15:35.05 | CoreDump|home | pop wq checking: Playback status: inactive waiting: yes |
15:35.05 | CoreDump|home | pop wq mute WM8731 Playback |
15:35.05 | CoreDump|home | pop wq D3 WM8731 Playback |
15:35.05 | CoreDump|home | [2 |
15:35.24 | CoreDump|home | checking the timing |
15:36.20 | RP | Ah, I know what it is. Tap the mic when you hear the static ;-) |
15:37.13 | RP | Check your mixer settings ;-) |
15:37.50 | CoreDump|home | no change ;) |
15:38.01 | CoreDump|home | i have capture muted |
15:38.37 | CoreDump|home | also "mute WM8731" and "D3 WM8731" only are printed after the static ends |
15:41.07 | Luke-Jr | um |
15:41.23 | Luke-Jr | should libtool symlink to build-arch staging? |
15:41.34 | CoreDump|home | http://hentges.net/tmp/Memo%20(2).amr this is a sound capture of the bug, can be played w/ mplayer |
15:41.54 | *** join/#oe Greg2_ (n=greg@pub86.hunt4.nfis.com) |
15:42.01 | Luke-Jr | wtf is amr |
15:42.17 | CoreDump|home | ask sony ericsson |
15:42.44 | Luke-Jr | 403 Forbidden |
15:42.45 | Luke-Jr | =p |
15:42.57 | CoreDump|home | err |
15:43.13 | RP | CoreDump|home: Is Output Mixer Line Bypass set? |
15:43.31 | CoreDump|home | Luke-Jr: fixed |
15:43.48 | Luke-Jr | mplayer can't play it |
15:43.54 | CoreDump|home | Output Mixer Line Bypass [Off] |
15:43.56 | CoreDump|home | mine can |
15:44.21 | CoreDump|home | Output Mixer Mic Sidetone Switc [Off] |
15:44.35 | RP | CoreDump|home: I know it sounds mental but try turning that on |
15:44.35 | CoreDump|home | Store DC Offset [Off] |
15:44.42 | RP | (line bypass) |
15:44.51 | CoreDump|home | same game |
15:44.52 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
15:45.40 | RP | CoreDump|home: Can you mail me your mixer settings (/etc/asound.state)? |
15:45.46 | CoreDump|home | sure |
15:48.54 | *** join/#oe Greg2 (n=greg@pub86.hunt4.nfis.com) |
15:48.55 | CoreDump|home | RP: http://hentges.net/tmp/asound.state |
15:49.02 | Greg2 | re |
15:49.11 | CoreDump|home | wb Greg2 |
15:49.25 | Greg2 | damn dail-up |
15:49.28 | *** join/#oe zecke (n=ich@88.134.2.26) |
15:49.53 | Greg2 | CoreDump|home: in regard to ts |
15:49.56 | Greg2 | CoreDump|home: i checked again and i do have PR= ?r40? and it has installed r40 |
15:50.03 | Greg2 | sorry for the mix up :) |
15:50.10 | CoreDump|home | well, that should work then |
15:51.06 | CoreDump|home | my local tslib is in sync w/ .oz |
15:51.49 | Greg2 | ? |
15:52.12 | CoreDump|home | meaning I didn't forget to push any changes |
15:52.25 | Greg2 | ok |
15:52.43 | CoreDump|home | And I built opie-image yesterday and it worked out-of-the-box w/ r40 |
15:53.10 | *** join/#oe punk-ass (n=user@ptbynynas01pool0-a38.ptbyny.tds.net) |
15:53.33 | Greg2 | i did a pull and update yesterday |
15:54.21 | zecke | Laibsch: ping :) |
15:54.43 | Laibsch | pong |
15:54.47 | Greg2 | my opie-image won't let me past the calibrate screen :( |
15:54.57 | Laibsch | zecke:pong |
15:55.33 | CoreDump|home | can you SSH in? |
15:56.06 | Greg2 | i'll have to leave here soon... will try later today |
15:56.07 | CoreDump|home | pastebin your /etc/profile.d/tslib.sh for me |
15:56.20 | CoreDump|home | yeah, no hurry |
15:56.26 | Greg2 | heh |
15:56.27 | zecke | Laibsch: I'm scared, but your log in the latest error report |
15:56.33 | zecke | Laibsch: lacks the source of the error :) |
15:57.01 | zecke | Laibsch: so please attach everything from the last 'arm-linux-g++' occurence until the end of the log |
15:57.03 | Laibsch | OK, that backtrace was very long. |
15:57.12 | Laibsch | OK. |
15:57.48 | Greg2 | CoreDump|home: thanks again for your help :) |
15:57.50 | zecke | Laibsch: you don't need to attach everything |
15:57.58 | Greg2 | bye all |
15:58.01 | CoreDump|home | Greg2: you're welcome |
15:58.15 | *** part/#oe Greg2 (n=greg@pub86.hunt4.nfis.com) |
15:58.30 | *** join/#oe AvengerMoJo (n=alex@219.142.252.174) |
15:59.51 | CoreDump|home | "Liam is a noob! I?m the real author of ASoC." |
15:59.55 | CoreDump|home | lol wtf? |
16:00.08 | zecke | CoreDump|home: where is that from? |
16:00.21 | CoreDump|home | A not-yet approved comment on oz.org |
16:00.45 | zecke | CoreDump|home: is that comment created by God? |
16:00.50 | CoreDump|home | Name: Mike Arthur | |
16:01.55 | zecke | hehe |
16:02.11 | koen | :) |
16:02.20 | CoreDump|home | I don't get it |
16:02.40 | koen | Mike Arthur is the summer intern at wolfsson iirc |
16:02.41 | zecke | CoreDump|home: From yesterday I know: Mike Arthur is a student working at Wolfson |
16:02.54 | RP | CoreDump|home: Your mixer settings work fine for me :-/ |
16:03.02 | CoreDump|home | RP: thought so :\ |
16:03.36 | CoreDump|home | zecke: well, I'm going to approve the comment since it isn't spam. |
16:03.49 | zecke | CoreDump|home: yeah, let Liam fight back :) |
16:04.24 | CoreDump|home | http://openzaurus.org/wordpress/2006/07/12/sound-support-for-poodle26/ |
16:05.29 | RP | It could be argued I was at least a joint author :) |
16:06.55 | CoreDump|home | ~lart mike |
16:07.23 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
16:09.02 | RP | CoreDump|home: I've reproduced it :). Had to load your mixer settings and reboot. Something in the mixer isn't taking affect until after a reboot and can't be changed once set |
16:09.15 | koen | ~seen mikearthur |
16:09.21 | ibot | mikearthur <n=mike@194.70.145.210> was last seen on IRC in channel #oe, 1d 2h 18m 53s ago, saying: 'zecke: he will *hopefully* complete touch and battery :D'. |
16:09.31 | CoreDump|home | interesting |
16:10.00 | RP | I suspect the logic on that control is inverted, just for fun |
16:10.05 | CoreDump|home | could you send me your working .state? |
16:10.23 | RP | I overwrote it :} |
16:10.27 | CoreDump|home | =D |
16:10.56 | CoreDump|home | so Output Mixer Line Bypass [Off] -> ON and reboot |
16:11.48 | CoreDump|home | well, how do you load your asound.state on reboot? (since zaurusd is AWOL from the poodle images) |
16:13.10 | RP | alsactl restore |
16:13.31 | RP | It only takes effect the first time its run for some settings seemingly, like the speaker |
16:19.00 | CoreDump|home | no luck w/ Output Mixer Line Bypass |
16:24.41 | *** join/#oe Kerwood_ (n=Marshall@69-174-191-58.frdrmd.adelphia.net) |
16:24.47 | CoreDump|home | no luck w/ Input Mux [Mic] |
16:25.50 | RP | Its likely this will become easy to debug, once we fix the controls issue :-/ |
16:26.20 | CoreDump|home | indeed |
16:30.56 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
16:35.17 | *** join/#oe Kerwood_ (n=Marshall@69-174-191-58.frdrmd.adelphia.net) |
16:38.47 | Luke-Jr | zecke: is "Remember to add `AC_PROG_LIBTOOL' to `configure.ac'. |
16:38.47 | Luke-Jr | " possibly related? |
16:39.24 | zecke | Luke-Jr: probably, but the question is. Where is the libtool version coming from |
16:42.19 | Luke-Jr | zecke: the libtool from the normal BB for libsigc++ is different from the one if I prepend libtoolize --force to configure |
16:42.48 | zecke | Luke-Jr: So sigc++ comes with a custom version of libtool? |
16:47.43 | Luke-Jr | no clue |
16:47.53 | Luke-Jr | I just know the current BB doesn't run libtoolize on it |
16:48.15 | Luke-Jr | and that even if I run it manually in do_configure_prepend, it doesn't fix the problem |
16:48.48 | zecke | Luke-Jr: So to summarize |
16:49.20 | Luke-Jr | my guess is that since AC_PROG_LIBTOOL isn't in configure.ac, the makefiles are not using the 'libtool' in the working dir, but rather trying to use a system 'libtool' |
16:49.37 | zecke | Luke-Jr: You didn't untar sigc++, and you didn't look if there is a libtool, and you didn't see how it is generated. And you didn't look at sqlite to check if it had a similiar issue (regarding to libtool?) |
16:50.03 | RickSeymour | Whats the best way that i can compile my own programmes with OZ3.5.4/Poodle.. |
16:50.24 | RickSeymour | (i need to recompile nsqld.... doesnt work) |
16:50.27 | Luke-Jr | there's no libtool until after configure executes |
16:50.31 | Luke-Jr | in sigc++ |
16:50.35 | Luke-Jr | there is a ltmain |
16:50.56 | Luke-Jr | sqlite's problem is entirely another matter, unrelated to sigc++ or libtool |
16:51.38 | Luke-Jr | if I have bitbake run libtoolize on sigc++, the resulting 'libtool' generated by configure is different than otherwise |
16:51.50 | Luke-Jr | however, the .la still ends up with build-system info |
16:52.22 | zecke | Luke-Jr: so the libtool patch in sqlite doesn't have to do with libtool? |
16:52.38 | Luke-Jr | RickSeymour: setup your OE environment to target that DISTRO/MACHINE and write a BB |
16:53.03 | Luke-Jr | zecke: I haven't seen anything in sqlite regarding libtool, and the problem with sqlite is not related to libtool |
16:53.03 | *** join/#oe benlau (n=benlau@221.125.13.148) |
16:53.31 | zecke | Luke-Jr: 'the' problem. I have asked you to look at existing patches to sqlite |
16:53.41 | zecke | Luke-Jr: to take that an inspiration to solve your libtool issue |
16:53.46 | zecke | as an... |
16:53.48 | Luke-Jr | oh |
16:54.04 | Luke-Jr | I thought you were referring to the pointer size problem with sqlite |
16:55.21 | zecke | e.g. how is the 'libtool' file called? |
16:55.35 | zecke | is it called arm-linux-libtool or just libtool |
16:55.40 | Luke-Jr | @LIBTOOL@ |
16:55.52 | zecke | then check config.log why it thinks x86_64/lib is a good path |
16:56.44 | Luke-Jr | config.log makes no mention of x86_64-linux/lib |
16:56.53 | Luke-Jr | and only 'x86_64' with regard to the build system |
16:57.53 | Luke-Jr | with 1 exception maybe |
16:57.55 | Luke-Jr | --with-mpfr=/home/luke-jr |
16:58.02 | Luke-Jr | --with-mpfr=/home/luke-jr/src/oe2005/build.alt/tmp/staging/x86_64-linux |
16:58.40 | Luke-Jr | libtool is called in practise as /bin/sh ../libtool |
17:00.03 | Luke-Jr | the mpfr is in a line starting with "Configured with: /home/luke-jr/src/oe2005/build.alt/tmp/work/armv5te-linux/gcc-c |
17:00.04 | Luke-Jr | ross-4.1.1-r5/gcc-4.1.1/configure" |
17:00.05 | zecke | that is bad :) |
17:00.11 | zecke | hmm |
17:00.16 | Luke-Jr | which part? |
17:00.20 | zecke | brb |
17:00.24 | zecke | this mpfr line |
17:00.34 | Luke-Jr | oh, so the problem is actually in gcc? |
17:02.58 | *** join/#oe mithro (n=tim@ppp246-117.static.internode.on.net) |
17:03.29 | zecke | might be :) |
17:03.45 | zecke | it is not too easy to look into your system from here :) |
17:04.25 | zecke | Luke-Jr: a to be cross compiled source should never ever point to the host (for includes and libs) |
17:04.58 | zecke | Luke-Jr: if it is calling libtool has 'libtool' we have a bug (maybe a unrelated one) |
17:06.19 | *** join/#oe Timelord0 (n=TL@4.78.4.43) |
17:21.31 | *** join/#oe csmanx (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
17:34.55 | Luke-Jr | zecke: the config.log mention of mpfr was in the context of GCC's configured arguments |
17:35.28 | Luke-Jr | zecke: do you have a SSH public key I can grant you access with? |
17:35.52 | zecke | I wouldn't have the time to look into it now :( |
17:36.05 | zecke | Luke-Jr: I'm about to start a build myself now |
17:36.14 | zecke | Luke-Jr: and I assume this behaviour is deterministic |
17:36.51 | Luke-Jr | zecke: the problem does not occur on x86_32 |
17:37.00 | zecke | Luke-Jr: hmm, it should :) |
17:37.06 | zecke | Luke-Jr: it might just 'work' |
17:37.15 | Luke-Jr | right, that's what I mean |
17:38.27 | zecke | Luke-Jr: well. I will take a look at the log files |
17:42.29 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
18:01.14 | CIA-9 | 03koen 07org.oe.dev * r67295511... 10/packages/linux/ (4 files in 2 dirs): ep93xx-kernel: add derevo20, drop old stuff |
18:01.18 | CIA-9 | 03koen 07org.oe.dev * rdbdf30b8... 10/packages/linux/ep93xx-kernel/defconfig: ep93xx-kernel: fix defconfig |
18:01.29 | *** join/#oe katossi (n=guillerm@dslb-084-061-014-232.pools.arcor-ip.net) |
18:02.38 | *** join/#oe darkschneider (n=gab@213-140-6-96.ip.fastwebnet.it) |
18:05.23 | *** join/#oe JaMa (n=martin@njama.ipv6.mk.cvut.cz) |
18:09.02 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
18:15.44 | *** join/#oe toi (n=peter@d54C27365.access.telenet.be) |
18:22.43 | *** join/#oe katossi (n=guillerm@dslb-084-061-014-232.pools.arcor-ip.net) |
18:23.25 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
18:37.30 | *** join/#oe dfoley (n=dfoley@d66-183-157-132.bchsia.telus.net) |
18:48.58 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
18:52.24 | *** join/#oe mallum (n=mallum@host81-132-227-111.range81-132.btcentralplus.com) |
18:52.43 | *** part/#oe dfoley (n=dfoley@d66-183-157-132.bchsia.telus.net) |
19:02.53 | *** join/#oe Kerwood_ (n=Marshall@69-174-191-58.frdrmd.adelphia.net) |
19:10.29 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
19:28.13 | *** join/#oe gremlin[it] (n=gremlin@ppp-20-9.25-151.libero.it) |
19:28.38 | CIA-9 | 03coredump 07org.oe.oz354x * r39ab050e... 10/conf/machine/poodle-2.6.conf: poodle-2.6.conf: Remove orinoco-modules and add alsamixer / alsactl to boostrap. We should probably sync this with .dev at some point. |
19:28.42 | CIA-9 | 03coredump 07org.oe.oz354x * r106c566e... 10/packages/altboot/ (altboot_1.0.7.bb altboot_1.0.8.bb): altboot: Add 1.0.8, correcting poodle-2.6.conf and fixing tosa / 2.6 kbd support |
19:28.46 | CIA-9 | 03coredump 07org.oe.dev * r22c05a74... 10/packages/altboot/ (altboot_1.0.7.bb altboot_1.0.8.bb): altboot: Add 1.0.8, correcting poodle-2.6.conf and fixing tosa / 2.6 kbd support |
19:29.38 | Luke-Jr | zecke: let me know |
19:30.17 | zecke | yes, still compiling away |
19:30.32 | zecke | I have a slow machine |
19:31.27 | *** join/#oe aquadran (n=pablo@scummvm/undead/aquadran) |
19:33.24 | *** join/#oe minipanda (n=hzhang@219.236.27.35) |
19:36.59 | DataBeaver | Why does OE have an almost two years old libvorbis? |
19:37.35 | DataBeaver | Actually, it's probably even older. |
19:39.58 | DataBeaver | Two and half years, according to Debian changelogs. |
19:40.54 | zecke | DataBeaver: because nobody tested newer versions? |
19:43.50 | DataBeaver | ERROR: 'BBFILES' while parsing /home/tdb/src/OpenZaurus/org.openembedded.dev/packages/libogg/libogg_1.1.3.bb |
19:43.57 | DataBeaver | What's that trying to say? |
19:44.03 | zecke | dunno |
19:49.39 | DataBeaver | Well, taking weapons of mass destruction to the cache helped. |
19:50.40 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
19:56.58 | DataBeaver | libvorbis 1.1.2 and libogg 1.1.3 compile just fine, now let's see if they work too... |
19:57.35 | emte | DataBeaver, where did you get a Debian changelog for OE? |
19:58.26 | DataBeaver | Debian changelog and OE are not related. But I used Debian's changelog to guess the release date for libvorbis 1.0.1. |
19:58.49 | emte | and your Error sounds like you somehow mangled your BBFILES enviroment var after you started a build |
19:59.01 | emte | ah |
20:00.35 | emte | atleast that is my guess. If it happens again echo the variable and see if it matches what it is supposed to be |
20:01.14 | DataBeaver | k |
20:01.32 | emte | could be as simple as loging in-out and forgetting to reset the var |
20:02.20 | emte | all depends on your setup |
20:02.42 | DataBeaver | Hmh, libvorbis segfaults even now that the version matches what I built my program with. |
20:04.08 | emte | then you must have other bad juju happening |
20:04.53 | emte | disable stripping for it and try to figure out why? |
20:05.36 | DataBeaver | Guess I'll have to try that... |
20:05.59 | DataBeaver | Another weird thing is that when playing a wav file, top shows about 90% system CPU usage |
20:06.53 | DataBeaver | Maybe oprofile will help with that one... |
20:06.55 | emte | why is the weird? |
20:06.58 | emte | that* |
20:07.26 | DataBeaver | Because I can't imagine why it would take that much systime. |
20:07.39 | emte | myself i would expect on memory constrained devices to see more cpu usage as the data cannot be buffered as much |
20:07.45 | DataBeaver | usertime would be understandable, since my program is compiled without optimizations currently. |
20:08.50 | koen | most OE developers build against tremor (libivorbis) |
20:08.57 | emte | but i suppose you would have to ask one of the guys who do work with sound on actuall behaviour |
20:09.01 | koen | so the regular libvorbis could be broken |
20:09.06 | DataBeaver | hm. |
20:14.13 | DataBeaver | That presents the problem of libivorbis not being available for Debian. |
20:16.32 | DataBeaver | And about the CPU usage... On my PCs, the same program (unoptimized) takes barely any CPU time at all, so something's fishy. |
20:16.53 | zecke | DataBeaver: your PC has a floating point unit? |
20:17.42 | Luke-Jr | heh |
20:17.58 | Luke-Jr | DataBeaver: what codec does the WAV file contain? |
20:18.10 | DataBeaver | Plain PCM |
20:18.29 | DataBeaver | Hmh, the ARM not having an FPU could explain a thing or two... |
20:18.43 | Luke-Jr | Is libivorbis the one that doesn't use floats? |
20:19.47 | koen | libi(nteger)vorbis |
20:19.50 | *** join/#oe YoG (n=zevele@bzq-88-155-226-126.red.bezeqint.net) |
20:20.33 | DataBeaver | My code currently uses some floating-point computation even when none is needed |
20:20.47 | emte | why? |
20:21.06 | DataBeaver | 'cause it made the design simpler and is of no concern on normal PCs? |
20:21.22 | DataBeaver | So does the kernel emulate the FPU then and makes things slow? |
20:21.23 | Luke-Jr | is floating point math any different from integer math on systems with a FPU? |
20:21.24 | Luke-Jr | in speed |
20:21.30 | emte | yes |
20:21.41 | emte | but systems are so fast now its not very moticable |
20:21.42 | Luke-Jr | DataBeaver: either that or the compiler uses software fp |
20:21.43 | DataBeaver | I think the difference is pretty minimal these days |
20:21.51 | emte | noticable* |
20:21.54 | Luke-Jr | emte: floating point is slightly slower? |
20:22.00 | Luke-Jr | or faster? |
20:22.14 | emte | except in heavy math computations, and this is why the AS/400 etc still exist |
20:22.17 | DataBeaver | Slightly slower |
20:22.31 | DataBeaver | And then there's the special cases of NaNs and Infs which are pretty damn slow |
20:22.43 | DataBeaver | Okay then... I'll modify my code so it doesn't use floats... |
20:23.07 | nchip | Float variables are typically also larger that 32bit ints, so using floats extensivile has a larger memory cost |
20:23.25 | DataBeaver | IEEE float is 32-bit, double is 64-bit |
20:23.46 | emte | IEEE are unsigned i belive are they not? |
20:23.49 | Luke-Jr | but anyway, PCM shouldn't need a FPU, should it? |
20:23.50 | Luke-Jr | err |
20:23.54 | Luke-Jr | floating point math |
20:23.57 | DataBeaver | IEEE floats are signed |
20:24.05 | DataBeaver | I've never heard of unsigned floats |
20:24.33 | DataBeaver | Luke-Jr: Nope. In this case I could pretty much just copy the data from the file to ALSA. |
20:24.37 | emte | i use them, but its to handle register issues |
20:24.56 | Luke-Jr | so the question remains why his PCM WAV file uses 99% CPU |
20:24.56 | emte | allows full 32 bit access without losing a bit for sign |
20:25.04 | DataBeaver | What device supports unsigned floats? |
20:25.10 | emte | all |
20:25.16 | DataBeaver | really? |
20:25.17 | Luke-Jr | what compiler does? |
20:25.26 | emte | most i belive |
20:25.31 | Luke-Jr | or does the 'unsigned' prefix apply to everything? |
20:25.31 | zecke | some one considers merging? |
20:25.42 | Luke-Jr | certainly have never seen 'ufloat' |
20:25.44 | Luke-Jr | or udouble |
20:25.46 | DataBeaver | C++ at least defines floats to be signed. |
20:26.02 | emte | they default signed for obvious reasons |
20:26.26 | emte | but if you know you will never have negative numbers or handle it externally then you can use unsigned |
20:28.21 | emte | but most PC people never use it unless they are optimising code |
20:28.41 | *** join/#oe tkp_ (n=tom@81-179-24-207.dsl.pipex.com) |
20:30.18 | *** join/#oe Kerwood_ (n=Marshall@69-174-191-58.frdrmd.adelphia.net) |
20:31.45 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
20:33.00 | Luke-Jr | grr |
20:33.11 | Luke-Jr | my wife absolutely refuses to let me teach her the difference between signed and unsigned |
20:33.19 | Luke-Jr | -.- |
20:33.37 | DataBeaver | heh |
20:33.47 | DataBeaver | Not very computer-oriented, is she? |
20:34.04 | Kerwood_ | yah, she doesn't know how handy that info will be |
20:34.18 | emte | lol |
20:34.21 | emte | its easy |
20:34.29 | emte | 1+1 vs 1+1.1 |
20:35.05 | Luke-Jr | DataBeaver: she was in her high school's "computer elite" group thing |
20:35.10 | emte | or if its unsigned everything is positive |
20:35.48 | emte | anyone know where i put my black wire? |
20:35.51 | Luke-Jr | yes |
20:35.54 | Luke-Jr | but I'm not telling |
20:36.09 | emte | lol |
20:36.47 | Luke-Jr | until I have a working image |
20:36.47 | Luke-Jr | =p |
20:38.48 | emte | i'll give you a working image :P |
20:40.16 | emte | well i found my wire |
20:40.28 | emte | now to find my stash of wirewrap sockets |
20:40.35 | Luke-Jr | emte: I want to build it tho =p |
20:46.16 | DataBeaver | Okay, let's see if that works now... |
20:47.11 | DataBeaver | Seems to work. |
20:47.54 | DataBeaver | And it seems to use the int stuff too. |
20:48.01 | DataBeaver | Now to test it on my Z... |
20:53.14 | DataBeaver | Hm, doesn't quite work... |
21:10.17 | *** join/#oe redguy (n=mati@acv35.neoplus.adsl.tpnet.pl) |
21:12.01 | DataBeaver | Grr. It writes some amount of data to ALSA and then gets stuck with EAGAIN. |
21:17.36 | DataBeaver | dmesg shows a lot of lines like "soc: DAI[23:4] failed to match rate" |
21:18.00 | DataBeaver | And finalle "Match OK" and after that "spurious IRQ for DMA channel 0" |
21:18.40 | DataBeaver | mp3blaster doesn't generate that spurious interrupt. |
21:20.39 | DataBeaver | I wonder what I'm doing differently... |
21:23.42 | DataBeaver | Huh. Apparently mp3blaster doesn't use ALSA at all. |
21:25.30 | Kerwood_ | In other news, has this Werner Shulte fellow (http://www.uv-ac.de/openembedded ) been invited to contribute to the OE wiki? |
21:26.54 | zecke | yes |
21:27.07 | zecke | he seems to be busy at work, I haven't seen him in ages |
21:27.10 | zecke | ~seen uv1 |
21:27.13 | ibot | uv1 <n=uv@p508929E6.dip0.t-ipconnect.de> was last seen on IRC in channel #oe, 49d 13h 3m 39s ago, saying: 'RP: Thanks, will try ...'. |
21:27.13 | zecke | ~seen uv |
21:27.14 | ibot | uv <~sc@p50924353.dip0.t-ipconnect.de> was last seen on IRC in channel #oe, 545d 2h 24m 17s ago, saying: 'By'. |
21:27.20 | Kerwood_ | whoa |
21:29.22 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
21:50.52 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928113.dsl.bell.ca) |
22:27.08 | *** join/#oe W8TVI (n=me@166.165.159.126) |
22:31.54 | zwelch | are there other public trees than the OE tree? i.e. third party sources of BBPATH-compatible trees? |
22:32.37 | thejapa | zwelch: technically familiar tree is split |
22:33.38 | kergoth | zwelch: are you counting the multiple branches in the monotone repo? :P |
22:33.48 | kergoth | also, the repo openedhand.com uses is publicly accessible |
22:33.51 | zwelch | kergoth: not really ;) |
22:33.54 | kergoth | their distro, "poky" |
22:33.59 | kergoth | minimal repo for just that |
22:34.27 | zwelch | for a real example, i have my tree here: http://svn.minisplat.org/svn/src/trunk/build.d/dist/oe/ |
22:35.16 | kergoth | zwelch: http://svn.o-hand.com/repos/poky/trunk |
22:35.22 | RP | ~poky |
22:35.23 | ibot | [poky] http://projects.o-hand.com/poky, or a subset of OpenEmbedded, created by o-hand.com to testdrive some of their technology |
22:35.41 | zwelch | by adding it (or a path to an appropriate tagged branch, for releases) to BBPATH, there is really no point to add my files to the main OE tree, right? (social reasons aside... but that's part of this discussion too ;) ) |
22:36.45 | kergoth | BBPATH doesnt find bb files, its for classes/conf. you'd use collections and bbfiles for the packages themselves |
22:36.52 | kergoth | but yes, theres no need to maintain everything in one repo |
22:37.11 | zwelch | so, i would guess that i am not the first person to suggest splitting the main OE repo into several smaller package repositories |
22:37.13 | zecke | BB Collections can help as well |
22:37.35 | kergoth | zwelch: the problem becomes, where do you split? |
22:38.01 | zwelch | kergoth: yes, that becomes the "i believe" part of the discussion; there is no "right" answer |
22:38.12 | zecke | zwelch: what we might do one time. Is creating 'views' of the MetaData |
22:38.35 | zecke | zwelch: e.g. using test results to give you a known working copy for a specific task |
22:38.36 | kergoth | zwelch: i'd argue that its better to have one repository than to start throwing around completely arbitrary boundaries.. |
22:38.37 | zwelch | zecke: i am interested in these collection things, but i don't recall reading much about them in the docs |
22:39.08 | zwelch | kergoth: i agree for the most part; there are pros and cons of each approach, but intertia has a big play in it too |
22:39.15 | zecke | zwelch: see the BitBake manual. |
22:39.31 | zecke | zwelch: e.g BB Collections help you to ease 'forks' |
22:39.35 | kergoth | zwelch: optimally, what i'd want is more of a split than is currently possible with bitbake |
22:39.46 | zecke | zwelch: rewrite bits one by one while allowing you to easily merge |
22:39.51 | kergoth | zwelch: i'd want to split all distro specific metadata into a repo for that distro, including the distro specific modifications to each .bb, which is the hard part |
22:40.01 | kergoth | heh |
22:41.20 | zwelch | kergoth: i agree with you there |
22:41.59 | zwelch | thinking about my possible win32 (which i think i am going to shop around to a couple of clients after some more thought), there is no way i would want all that crap in the main repo |
22:42.34 | zecke | back to work... |
22:42.41 | zwelch | as much as possible, it should build on top of - but separately from - the main OE repo |
22:42.46 | kergoth | its difficult, since you'd need to track the -delta- against the original .bb, so if the original changes, you may need to adapt... itd be like maintaining patches, but managed by bb |
22:43.26 | emte | i'd still settle for a Core, GPE, Opie, QTE, X11, and Optional repos |
22:43.39 | zwelch | yeah, it's definitely non-trivial; however, my initial example that started this was in the context of files that do not exist in any form in the upstream repo |
22:44.56 | zwelch | i mean, if partitioning things along logically sane lines is feasible and desirable, it seems like i have established a reasonable means for delivering these files |
22:45.16 | zwelch | in the main repo, i'd only want a conf file that could "include <url>" :) |
22:45.30 | zwelch | i.e. figure out to download the additional repos automatically |
22:45.50 | zwelch | kergoth: does any of that make sense to you? |
22:46.01 | emte | bitbake isnt that smart yet, we have big hopes for BB-ng from kergoth :P |
22:46.58 | zwelch | emte: the kind of split you suggested may seem feasible at first, but i suspect there would be too much overlap and maintenance costs (caused by the kinds of upstream tracking that kergoth mentioned) |
22:47.00 | emte | if bitbake starts using the sqlite backend then you could walk your intended build to get files and generate graphs |
22:47.36 | zecke | it can generate graphs now as well... :) |
22:47.40 | zwelch | well, you don't need sqlite to do that; though, i admit you might need it to do it in a timely manner ;) |
22:48.02 | emte | zecke, yeah but not the kind needed for it to be smart |
22:48.20 | *** join/#oe |dkey| (n=dkey@192-186-stud-adsl.wu-wien.ac.at) |
22:49.14 | emte | as each package generates a branch of more deps and provides, with sql you can join them all back into one stream to build in the correct order |
22:49.33 | zecke | I'm too tired to keep up forking between irc and work |
22:49.35 | zecke | later pals |
22:49.39 | emte | night Zero_Chaos |
22:49.42 | emte | lol |
22:49.48 | emte | tab not fast enough |
22:52.22 | emte | but yeah i agrre with the package overlap posibility |
22:52.32 | emte | agree* |
22:54.13 | *** part/#oe Laibsch (n=Laibsch@V30c7.v.pppool.de) |
22:56.39 | thejapa | wasn't koen's google project about making it better to use? |
22:56.46 | thejapa | it=monotone/bb |
22:57.28 | emte | i doubt OE will get any support from google any time soon |
22:57.45 | emte | unless someone files for nonprofit status |
22:57.57 | *** join/#oe Kerwood_ (n=Marshall@69-174-191-58.frdrmd.adelphia.net) |
22:58.30 | thejapa | http://code.google.com/soc/handhelds/appinfo.html?csaid=CED12F0DF30CA6C2 |
22:58.35 | kergoth | thejapa: no, his project is to make staging packaged and managed |
22:58.42 | thejapa | oh |
22:58.52 | kergoth | why the heck is it under handhelds.org? |
22:58.53 | kergoth | jesus |
22:59.41 | thejapa | i guess that was before the openembedded.org |
22:59.49 | emte | because hh.o is a registered nonprofit organization |
23:00.51 | kergoth | thejapa: openembedded.org has been around for years. it happened to be -hosted- by handhelds.org, but thats all |
23:00.55 | kergoth | ah well |
23:01.23 | emte | oe.o also has no administrative body |
23:01.57 | thejapa | hmm, it will take lots of time to understand all these things :) |
23:02.22 | emte | so technically oe.o doesnt exist |
23:02.31 | njs | you don't need a formal administrative body to do SoC :-) |
23:03.09 | njs | but OTOH, google doesn't want to sponsor multiple projects in the same area, so there are lots of umbrella-y setups for SoC |
23:03.35 | kergoth | they should call that section embedded linux then, and leave it at that |
23:03.40 | thejapa | yeah, there are evolution projects in ubuntu |
23:03.46 | thejapa | opensync in kde |
23:04.41 | RP | kergoth: hh.org had the infastructure and people to run a set of SoC projects. I suspect OE on its own would have been overlooked |
23:06.02 | kergoth | infrastructure? |
23:06.57 | emte | not sure on that one myself |
23:07.13 | njs | nmap the last two years did SoC with 10-15 students and 1 admin/mentor |
23:07.17 | njs | fyodor is a busy guy :-) |
23:07.20 | thejapa | imo, hh.org is the portal for ipaq users, so it gets all popularity, that makes it easier to get chosen by google. |
23:07.38 | emte | i am not sure that is correct |
23:07.42 | njs | the actual way google chose projects though is all mysterious and random, so *Shrug* |
23:07.47 | kergoth | i disagree, i think oe just hasnt been marketed well. |
23:07.49 | emte | there are FAR more zaurii devs than ipaq |
23:08.14 | thejapa | in brazil you can count the zaurii in one president's hand i guess :) |
23:08.23 | thejapa | (our president has 4 fingers) |
23:08.32 | RP | kergoth: They'd done it before, had people who knew people, had someone to act as an admin, could show more financial backing than we can, are a "proper" organisation etc. |
23:08.39 | emte | dont most people on each nad? |
23:08.42 | emte | hand* |
23:08.48 | kergoth | RP: njs just contradicted you on that, so.. |
23:09.00 | njs | oh, umm, "done it before" was an automatic qualification this year |
23:09.15 | RP | kergoth: OE hasn't had the marketing which does put us at a disadvantage for things like this |
23:09.28 | RP | kergoth: not on every point he didn't |
23:09.33 | thejapa | mind if I ask, what happened to last year students? disappeared? |
23:09.40 | njs | (and last year it was a mad scramble and almost random who got in, so whether a gropu had done it before is also random) |
23:10.09 | emte | thejapa, gremilin still pops in and does work |
23:10.14 | Luke-Jr | kergoth: re splitting "distro specific modification", I have plans for such an architecture for a package manager planned |
23:10.17 | kergoth | RP: those might be beneficial, but no means prevented the numerous other project from getting in, and oe would still have had a shot on its own |
23:10.31 | kergoth | Luke-Jr: have a wiki page on it somewhere? |
23:10.57 | Luke-Jr | kergoth: not really, just notes |
23:11.03 | emte | i can tell you that enlightenment has had project presented in the last few and always been turned down |
23:11.04 | pb_ | kergoth: yah; clearly the main reason that oe didn't get into SoC is that nobody filed an application. |
23:11.08 | kergoth | hehe |
23:11.08 | Luke-Jr | the idea is based on Portage's USE flags, except making them modular |
23:12.02 | RP | kergoth: You've also ignored my people point - we don't have the people |
23:12.02 | emte | Luke-Jr, you aware that the portage-c people were contected at one point? |
23:12.16 | Luke-Jr | emte: contacted about? |
23:12.35 | emte | bitbake i belive, kergoth could probably tell you the outcome |
23:12.57 | Luke-Jr | but what about them? I need a verb of some sort =p |
23:13.53 | Luke-Jr | kergoth: actually, OE can handle something similar-- it has the ability to insert steps and such |
23:14.24 | Luke-Jr | kergoth: project-specific changes could be a new BB built on the vanilla one, but inserting a customize step |
23:14.42 | kergoth | i'd still like to see a capable metadata management and recipe execution library with modular parsers/metadata formats, which could be used as the backend for both a new bitbake and other actual package management tools |
23:17.40 | Luke-Jr | you mean more-or-less recipe plugins? |
23:17.50 | Luke-Jr | eg, a plugin could be created to handle Gentoo's ebuilds? |
23:18.41 | kergoth | thatd be the idea, though ebuilds are problematic since they're not directly parsed |
23:19.59 | Luke-Jr | why not modularize also the execution of recipes? |
23:20.27 | Luke-Jr | so a plugin to use RPM (for example) as a 'receipe'/source might be possible? |
23:20.45 | emte | bitbake already supports rpm i belive |
23:20.47 | Luke-Jr | in which case, a ebuild plugin could probably be a patch or wrapper to Gentoo's Portage programs |
23:20.53 | kergoth | it does, bitbake supports src.rpm |
23:21.00 | Luke-Jr | emte: as a recipe? |
23:21.10 | kergoth | yes, you can use a src.rpm directly |
23:21.16 | kergoth | it extracts the metadata and converts it to bitbake's |
23:21.23 | kergoth | then it can emit a binary rpm or ipk or whatever |
23:21.31 | Luke-Jr | what about a binary RPM? ;) |
23:21.53 | Luke-Jr | (yes, it'd be pointless-- but as a test for abstraction) |
23:22.04 | kergoth | an rpm is an rpm from the metadata side, it could parse it fine but would have no recipes to execute |
23:22.09 | emte | that poses problems for obvious reasons |
23:22.19 | kergoth | you'd have to have a seperate .bbclass to do the legwork of ripping out the binaries for the steps |
23:22.53 | Luke-Jr | well, for a binary RPM there'd probably only be an unpack step before package/populate |
23:23.59 | kergoth | yeah, bitbake could do that today. not well, or cleanly, but.. ;) |
23:24.10 | Luke-Jr | hm |
23:24.20 | kergoth | following recipes is such a common thing though, its used everywhere, even in make and scons |
23:24.28 | kergoth | makes sense to have a capable flexible backend library |
23:24.35 | Luke-Jr | where are the package/populate steps defined anyway? Not at the receipe level, I presume |
23:24.55 | kergoth | Luke-Jr: base.bbclass for .bb files, base_srcrpm or somesuch.bbclass for src.rpm |
23:25.02 | kergoth | thats the base steps |
23:25.10 | kergoth | i think packaging is in package.bbclass and package_ipk.bbclass, etc. |
23:25.18 | kergoth | but i've been away, so that couldve changed recently and i wouldnt know |
23:25.23 | Luke-Jr | so a BB could delete the package step to prevent it from being packaged? |
23:26.20 | kergoth | pretty sure thatd work, it depends on whether package.bbclass gets pulled in before parsing the .bb or after, i |
23:26.33 | kergoth | but you could remove it from INHERITS if after, so yes, you could one way or another afaik |
23:27.00 | kergoth | i want a debianish distro using rpm for the binary packages and a tool like bitbake/oe to build those packages for installation |
23:27.03 | kergoth | one day |
23:27.18 | Luke-Jr | why RPM? |
23:27.26 | emte | the CPUS rpm i hope |
23:27.30 | emte | CUPS* |
23:27.45 | kergoth | personal preference, i like the way rpm does things more than i like the way dpkg does things |
23:27.56 | Luke-Jr | could BitBake handle the *installation* (merge) of the binary RPM to the base system? |
23:28.09 | kergoth | the preference on the source building side of the format is obviously leaning towards rpm, as .spec makes sense, debian's 'rules' is crap |
23:28.57 | kergoth | Luke-Jr: hmm, perhaps, but you might run into issues between build order vs installation order |
23:29.06 | kergoth | not sure, they've changed the depends handling recently |
23:29.08 | Luke-Jr | kergoth: eh? |
23:29.21 | Luke-Jr | oh yeah... the new depend handling doesn't work :( |
23:29.26 | Luke-Jr | would need to fix that for serious use |
23:29.35 | kergoth | not to mention we need versioned deps and all that |
23:29.38 | kergoth | currently its ewak |
23:29.39 | kergoth | weak |
23:30.05 | *** join/#oe woglinde (i=woglinde@e178089191.adsl.alicedsl.de) |
23:30.18 | Luke-Jr | right, BitBake needs everything it ripped out back when it was portage-based |
23:30.33 | Luke-Jr | USE flag equivalents, for example |
23:30.53 | kergoth | thats a tough one |
23:31.00 | Luke-Jr | is it? |
23:31.02 | kergoth | if you want to have a sane binary distro based on it, anyway |
23:31.15 | kergoth | since it isnt easy to distinguish a binary built one way vs one built another, is there? |
23:31.15 | Luke-Jr | well, I'm not interested in a binary distro ;) |
23:31.21 | kergoth | you'd have ot encode USE into the binary packages and such |
23:31.22 | Luke-Jr | yes |
23:31.44 | Luke-Jr | so long as you don't rely on a human identifying the packages |
23:31.44 | kergoth | ah, well yes, use without worrying about that isnt troublesome |
23:31.53 | kergoth | but USE is extremely limited, i dont like the flat namespace myself |
23:32.06 | Luke-Jr | well, I use "USE" as a generic term here |
23:32.11 | Luke-Jr | not a specific implementation |
23:32.12 | emte | i thought binary diff/identification tools existed |
23:32.16 | Luke-Jr | even Gentoo has left the flat namespace |
23:32.21 | kergoth | they do, but that wouldnt be useful here |
23:32.23 | kergoth | ah good |
23:32.24 | kergoth | finally :) |
23:32.32 | Luke-Jr | now they have USE, LINGUAS, VIDEO_CARDS, etc |
23:32.43 | RP | Luke-Jr: Why doesn't the new depends handling work? |
23:32.46 | kergoth | not unlike OE today then. we have IMAGE_LINGUAS, etc |
23:32.46 | Luke-Jr | which are implemented as linguas_* USE flags within ebuilds |
23:32.53 | kergoth | just a bit fancier |
23:33.03 | Luke-Jr | RP: no idea; it seemingly randomly decides to skip dependencies for me |
23:33.30 | Luke-Jr | RP: on *-image anyhow |
23:33.32 | Luke-Jr | and tasks |
23:33.33 | Luke-Jr | and such |
23:33.35 | RP | Trust me, its not random and it usually has good reason ;-) |
23:33.44 | Luke-Jr | Not that I can determine, though |
23:33.54 | Luke-Jr | here's the simplest case... |
23:34.03 | Luke-Jr | I start with a empty 'tmp' |
23:34.12 | Luke-Jr | I tell it to build gpe-image |
23:34.23 | CIA-9 | 03freyther 07org.oe.dev * rf74c5b28... 10/conf/distro/openzaurus-unstable.conf: (log message trimmed) |
23:34.23 | CIA-9 | conf/distro/openzaurus-unstable.conf: binutils 2.16 is preferred |
23:34.23 | CIA-9 | <PROTECTED> |
23:34.23 | CIA-9 | <PROTECTED> |
23:34.23 | CIA-9 | <PROTECTED> |
23:34.24 | CIA-9 | <PROTECTED> |
23:34.24 | Luke-Jr | it begins building deps |
23:34.25 | CIA-9 | <PROTECTED> |
23:34.28 | Luke-Jr | errors somewhere |
23:34.40 | Luke-Jr | and when I tell it to 'build gpe-image' again, it skips deps and goes right to gpe-image |
23:35.23 | Luke-Jr | I had that happen at least twice |
23:35.45 | RP | Luke-Jr: Ah. I can guess why it would do that in certain cases. It will assume if something is built, it doesn't need to build its dependencies |
23:36.09 | Luke-Jr | RP: that would be a problem if it builds dependencies AFTER the package itself... |
23:36.48 | Luke-Jr | but that also wouldn't explain why sometimes it will suddenly notice the dependencies again |
23:37.17 | RP | I can't wait to rewrite the dependency handling code ;-) |
23:37.22 | Luke-Jr | heh |
23:37.31 | Luke-Jr | glad it's planned =p |
23:37.49 | RP | Its started as it happens ;-) |
23:37.55 | Luke-Jr | just wish I could build a OZ-unstable gpe-image |
23:38.05 | Luke-Jr | right now |
23:38.30 | Luke-Jr | I should have used one of my x86_32 systems for OE... too many problems with 64-bit and OE |
23:40.26 | woglinde | nite |
23:45.40 | RP | 'night all |
23:47.01 | kergoth | night |
23:48.06 | DataBeaver | Funny, even without floats my program still takes 30% CPU. |
23:48.16 | DataBeaver | Most of it systime. |
23:52.05 | *** join/#oe Pendalar (i=pendalar@h138.239.213.151.ip.alltel.net) |
23:52.34 | *** join/#oe cinix (n=Matt@69-163-33-37.lndnnh.adelphia.net) |
23:58.37 | emte | DataBeaver, what is your cpu freq? |
23:58.49 | emte | and what is the bitrate of the file? |
23:59.42 | emte | and 30% is quite a saving, down from 90% |