**** BEGIN LOGGING AT Sat Jul 15 02:59:56 2006 Jul 15 03:21:09 hvontres|home: ? Jul 15 03:21:15 hvontres|home: errr...pong Jul 15 03:22:21 JustinP: hi. I am installing the images right now... just wanted to see if you were still around Jul 15 03:23:55 hvontres|home: cleaning, so in and out Jul 15 06:04:05 <|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? Jul 15 06:09:48 |BundaBRG|z you should be using the oz354x branch if you're ocmpiling for an OZ 3.5.4.1 release Jul 15 06:10:48 <|BundaBRG|z> Thanks. I thought as much. Jul 15 07:32:47 morning all Jul 15 07:33:01 morning RP Jul 15 07:33:46 RP: have you heard of anybody using image files with altboot on 2.6.17? Jul 15 07:34:15 hvontres|home: no, but I don't see why 2.6.17 would make a difference Jul 15 07:34:56 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. Jul 15 07:35:55 I'll try to catch CoreDump later.. Jul 15 07:36:53 hvontres|home: maybe loopback support is missing...? perhaps some e2fstools missing? Jul 15 07:36:59 hvontres|home: I don't really use altboot so he'd be the better person to talk to Jul 15 07:37:30 * JustinP uses it all the time Jul 15 07:37:44 never booted from an image on SD, though Jul 15 07:37:51 * JustinP hugs his spitz Jul 15 07:38:10 JustinP: I can mount the loopback file, but it will hang during boot. Jul 15 07:38:43 For now I made four partitions on my 1GB card.. 1 common, 1 for gpe, 1 for e and 1 for opie..:) Jul 15 07:38:51 hang where? Jul 15 07:39:03 I assume they're my images.... Jul 15 07:39:14 they *could* have 2.4 thing in them....although they shouldn't Jul 15 07:39:23 but if a partition works.... Jul 15 07:40:01 JustinP: depends. your gpe image hangs on loading the keymap, e hangs during udev and my opie image during portamap Jul 15 07:40:47 JustinP: e image is going through first boot now... calibration just came up :) Jul 15 07:41:37 yeah, takes a while Jul 15 07:41:49 I've been meaning to use qemu to do the menu generation Jul 15 07:41:59 but have had so little testing in general that.... Jul 15 07:42:18 JustinP: The touchscreen cal seems to be stuck in an endless loop :( Jul 15 07:43:06 that's not a good sign... Jul 15 07:43:07 ugh Jul 15 07:43:18 I don't know why some people have problems with entrance not working Jul 15 07:43:38 Fn-Alt-Backspace to kill X Jul 15 07:44:09 well...not sure what it would be on poodle Jul 15 07:44:23 ~poodle Jul 15 07:44:26 extra, extra, read all about it, poodle is sharp sl-b500/5600, or a dog Jul 15 07:44:35 ah....that one.... Jul 15 07:44:44 RP: where did you guys put the alt key on poodle? Jul 15 07:45:03 you may have problems with screen size. AFAIK e was never tested on a 320x240 screen Jul 15 07:45:16 hvontres|home: I don't know - I didn't write the keymap Jul 15 07:45:25 heh, it is now :) Jul 15 07:45:29 you could also use a USB connection to SSH in and kill Xfbdev Jul 15 07:45:50 or wireless of whatever....not that you can set up wireless without some input Jul 15 07:46:17 let me check the wiki... Jul 15 07:47:19 56 or 67 perhaps? Jul 15 07:47:55 (not that I know what ley that is) Jul 15 07:48:02 * JustinP tired Jul 15 07:48:37 Address button Jul 15 07:48:53 I think Jul 15 07:49:26 keycode 56 = SAlt # Address Jul 15 07:49:44 tried that... no dice... Jul 15 07:50:06 hmm, and I need a console to set up usb...:( Jul 15 07:51:16 the default won't work? Jul 15 07:51:49 need to load g_ether by hand... Jul 15 07:52:42 still need to fix that Jul 15 07:53:06 thanks for the image.. will need to work on that some more... later. Jul 15 07:53:14 Time for bed Jul 15 07:54:15 you can always boot to something else and edit its files ;-) Jul 15 07:54:17 sleep well Jul 15 07:54:20 * JustinP sleeps as well Jul 15 07:55:40 I'll give gpe a shot now..:) Jul 15 07:58:05 CoreDump|afk: have you tested loop images off sd on your poodle yet? Jul 15 08:21:28 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) Jul 15 09:07:40 hi there... wheres our buzgilla? Jul 15 09:07:44 bugzilla Jul 15 09:12:07 RickSeymour: I suspect it's trying to run in ipv6 mode Jul 15 09:12:21 RickSeymour: bugs.openembedded.org Jul 15 09:14:33 03mickeyl * r549 10bitbake/lib/bb/msg.py: msg needs to import sys, it calls it Jul 15 09:16:17 whee, bitbake commits Jul 15 09:17:32 yay :) Jul 15 09:25:35 <|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 Jul 15 09:28:18 |BundaBRG|z: The xlibs were reworked in .dev and some were renamed. That's unlikely to be the real problem Jul 15 09:29:51 <|BundaBRG|z> Yeah, xext compiles fine. Jul 15 09:37:26 03mickeyl 07org.oe.dev * r0f90c48c... 10/classes/sanity.bbclass: Jul 15 09:37:26 sanity.bbclass: relax the DISTRO check a bit, taking into account that some DISTRO configurations Jul 15 09:37:26 override DISTRO before sanity.bbclass gets a chance to see it. By definition, in this case $RENAMED_DISTRO Jul 15 09:37:26 needs to be present in distro/include/ though, so we have a second chance for the test to succeed. Jul 15 09:53:41 I see, that is why my OE was acting up again. And I thought it was me, checking DISTRO over and over again. Jul 15 09:55:57 sorry Jul 15 09:58:37 np Jul 15 09:59:00 a few things will still not compile anyhow. Jul 15 09:59:09 poboxserver among them. Jul 15 09:59:25 how does it bail out? Jul 15 11:02:27 morning Jul 15 11:04:16 * CoreDump|home just spent 6hrs installing windows98 on his work siemens "PG" Jul 15 11:05:30 what? Jul 15 11:05:44 there are now security patches anymore Jul 15 11:05:48 no Jul 15 11:05:54 hehe Jul 15 11:06:20 the poor P$something 233MHz doesn't care about that ;) Jul 15 11:06:35 linux Jul 15 11:06:36 linux Jul 15 11:06:53 I can't :\ Jul 15 11:07:04 why? Jul 15 11:07:17 I need Siemens Step5 software (beside other windows/DOS stuff) Jul 15 11:07:32 hm Jul 15 11:08:17 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) Jul 15 11:09:05 * CoreDump|home *hates* working on ancient hardware Jul 15 11:09:14 http://linuxdevices.com/articles/AT8243331060.html Jul 15 11:09:19 I need one Jul 15 11:09:21 I guess Jul 15 11:09:47 sweet Jul 15 11:10:21 damn it that I am not a friend of harald Jul 15 11:11:05 who's harald? Jul 15 11:11:11 laforge Jul 15 11:11:26 the openexzs guy Jul 15 11:12:39 ahh Jul 15 11:12:54 he is in shanghai right now Jul 15 11:13:01 and bought this phone already Jul 15 11:13:10 well, a (fully working!) mobile running (s hackable) linux would be indeed nice Jul 15 11:13:37 http://gnumonks.org/~laforge/weblog/2006/07/10/#20060710-rokr_e2 Jul 15 11:51:37 <|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? Jul 15 11:54:50 maybee the searching directories are wrong in oz branch Jul 15 12:04:38 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. Jul 15 12:16:58 <|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) Jul 15 12:22:46 bunda what does the config.log says? Jul 15 12:27:51 <|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 Jul 15 12:29:45 conftest.c:54:27: X11/Intrinsic.h: No such file or directory Jul 15 12:31:06 so you have to check if Intrinsic.h is in the X include dir Jul 15 12:36:52 <|BundaBRG|z> thanks, ill have a look Jul 15 12:46:46 <|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. Jul 15 12:47:08 no prob :) Jul 15 12:50:20 <|BundaBRG|z> whoo compiles :) Jul 15 13:25:37 hello everyone Jul 15 13:36:35 ~seen CoreDump|home Jul 15 13:36:45 coredump|home 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'. Jul 15 13:37:16 pinging me usually works fine when I'm around;) Jul 15 13:37:40 CoreDump|home ok Jul 15 13:38:26 CoreDump|home: have you built a 2.6.17 opie-image in oz354x with a working ts Jul 15 13:38:42 poodle Jul 15 13:40:48 Greg2: yeah, I've pushed a fix for poodle ts on 2.6 a few days ago Jul 15 13:41:21 CoreDump|home: i'm having trouble with my poodle 2.6.17 kernel opie-image... no working touchscreen :-( Jul 15 13:41:33 update your meta data Jul 15 13:41:49 i did yesterday Jul 15 13:41:59 and you rebuilt tslib? Jul 15 13:42:33 i built an image yesterday Jul 15 13:43:43 which PR of tslib is installed? r39 or r40? Jul 15 13:44:06 i'll check Jul 15 13:44:18 http://www.openembedded.org/viewmtn/getdiff.py?id1=0c38f65e94162e11d2eaf4f1d6484eb28b7b43a7&id2=6085cf4d41b528aee7379c2ef6b24e17a490e133 <- the fix Jul 15 13:45:47 I'm trying to install a package that needs klibc to build... Jul 15 13:46:24 I have installed the klibc package, yet klibc is not found in the path, so the build fails Jul 15 13:47:14 the klibc stufff got built into to tmp/staging/i586-oe-linux/klibc/lib/klibc Jul 15 13:47:27 r39 Jul 15 13:47:33 what's the best way to add this to my PATH in bitbake fassion? Jul 15 13:48:37 Greg2: your meta-data is not up-to-date then as OE would have built -r40 automatically Jul 15 13:49:34 hmm.. the klibc package doesn't even seem to have installed a klibc binary Jul 15 13:50:00 * CoreDump|home dunnos Jul 15 13:50:28 CoreDump|home: hmm, it picked up you keyboard patch Jul 15 13:51:05 i'll do a pull Jul 15 13:56:40 bytes in | bytes out | certs in | revs in | revs written Jul 15 13:56:41 monotone: 196 | 1,125 | 0 | 0 | 0 Jul 15 13:57:51 CoreDump|home: it's up to date Jul 15 13:58:00 what does @oe_filter_out do? Jul 15 13:58:06 as in TARGET_CFLAGS := "${@oe_filter_out('-I\S+', '${TARGET_CFLAGS}', d)} -I${STAGING_KERNEL_DIR}/include" Jul 15 13:58:42 Greg2: do "mt diff tslib" Jul 15 13:59:35 ~hail mickey|breakfast poboxserver does indeed compile now. Jul 15 13:59:37 * ibot bows down to mickey|breakfast poboxserver does indeed compile now. and chants, "I'M NOT WORTHY!!" Jul 15 13:59:47 ;-) Jul 15 14:00:35 sh*t, someones at my door... bbiab Jul 15 14:14:58 RP: youa round? I'm getting major distortions with poodles alsa driver. Jul 15 14:16:57 CoreDump|home: i'll have to get back to this later, i have visitors now :-/ Jul 15 14:17:01 CoreDump|home: thanks for your help Jul 15 14:17:42 bbl Jul 15 14:17:53 Greg2: np, have fun Jul 15 14:22:46 CoreDump|home: yes Jul 15 14:23:06 how can I completely override the cflags for oe_runmake? Jul 15 14:23:39 IIRC you were mentioning that poodles sound would work now. Well it makes "noise" =) Jul 15 14:23:55 CoreDump|home: It should work fine - at least it did for me Jul 15 14:24:00 CoreDump|home: Which application? Jul 15 14:24:49 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 Jul 15 14:25:33 So its not stopping playback? Jul 15 14:25:52 What happens if you then play a file with something like madplay or aplay? Jul 15 14:26:04 also playing with the "speaker" setting in alsamixer kills any sound output. Only rebooting helps at this point Jul 15 14:26:09 RP: will try Jul 15 14:26:31 CoreDump|home: The speaker setting in alsamixer is problematic at best Jul 15 14:26:41 =) Jul 15 14:27:06 CoreDump|home: Does the same thing come from the headphones and does the volume control change the volume level of the static? Jul 15 14:27:06 can it be disabled? That's going to confuse users a lot i guess heh Jul 15 14:27:41 CoreDump|home: We need to fix ASoC - its a known bug which XorA/lrg are looking into as it also appears on corgi Jul 15 14:27:44 didn't try headphones yet. Vol +/- changes noise output. The noise doesn't loop. Jul 15 14:28:02 kinda hard to explain hmm Jul 15 14:28:16 I'll try aplay or something like that Jul 15 14:28:30 It sounds like its locked playing static. This would be bug in ASoC Jul 15 14:28:38 (but the cat trick works nicely on akita and my notebook ;)) Jul 15 14:28:54 Yes, it should stop, I don't deny that :) Jul 15 14:29:17 RP: nah, it doesn't lock up. It plays the sound once, ending the play w/ static. Any further attempt results in only static Jul 15 14:29:44 CoreDump|home: Does a suspend/resume let you play the sound again? Jul 15 14:29:53 I'd test corgi if I hadn't just trashed its mtd :-( Jul 15 14:30:13 poodle doesn't like suspend w/ root on NFS ;) Jul 15 14:30:17 RP: ouch Jul 15 14:30:25 jffs2 is now broken in mainline kernels :-( Jul 15 14:31:05 I fixed the sharpsl NAND driver they also broke, only to have it trash all the data on the device :-( Jul 15 14:31:40 argh Jul 15 14:32:04 so .17 is the last usable kernel currently? Jul 15 14:32:20 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 Jul 15 14:32:28 where are they comming from? Jul 15 14:32:49 RP: same problem w/ aplay. a .wav file is played correctly, followed by static Jul 15 14:32:59 CoreDump|home: correct, I'd not recommend the git ones now Jul 15 14:33:06 CoreDump|home: Which toolchain is this? Jul 15 14:33:31 a (almost) clean .oz built from yesterday Jul 15 14:33:46 so gcc 3.4.4? Jul 15 14:34:06 gcc-cross-locale-be_3.4.4-r3_armv5te.ipk Jul 15 14:34:08 yep Jul 15 14:34:56 there goes that theory :) Jul 15 14:35:11 hehe Jul 15 14:35:18 let me search my headset Jul 15 14:37:11 ouch Jul 15 14:37:20 same static on the headset =) Jul 15 14:38:18 Do you want to try my kernel? I'd like to work out why yours does this and mine doesn't... Jul 15 14:38:33 sure Jul 15 14:39:28 Thankfully I still have it :) Jul 15 14:39:56 http://www.rpsys.net/openzaurus/temp/poodle/ Jul 15 14:40:06 I only have the modules.tgz, not the ipks I'm afraid Jul 15 14:40:33 np Jul 15 14:42:20 * CoreDump|home preps to trash his nfs root Jul 15 14:47:40 good morning all Jul 15 14:47:42 kexec'ed your kerneö Jul 15 14:47:47 morning koen Jul 15 14:53:35 RP: same problem w/ your kernel and modules :( Jul 15 14:54:54 CoreDump|home: Not good :-( Jul 15 14:57:42 This suggests hardware differences which I don't like the sound of (no pun intended) Jul 15 14:58:15 hehe Jul 15 14:58:21 I got a pxa255 here Jul 15 14:58:27 if that matters *shrug* Jul 15 14:58:49 how can I tell for sure if a libtool is from OE? Jul 15 14:58:55 I wonder if mine is a 250... Jul 15 14:59:16 Processor : XScale-PXA255 rev 6 (v5l) Jul 15 14:59:21 Mine is a 250 Jul 15 14:59:26 heh Jul 15 15:00:12 ok, the thing is: The sound is played correctly but after the file is played, static is produced for ~2s Jul 15 15:00:13 If anything, I'd have said this would work the other way around... Jul 15 15:00:24 Just 2s? Jul 15 15:00:29 yeah Jul 15 15:00:43 ok, more like 3... Jul 15 15:00:48 That's DAPM holding the sound chip open before shuttdown the power to it Jul 15 15:01:16 there is no trace of static in the sound itself when it is beeing played Jul 15 15:01:41 Right, so something in the shutdown is screwing up... Jul 15 15:02:14 and things don't play right again, even after waiting until after the 3seconds before playing again? Jul 15 15:02:26 they do play right Jul 15 15:02:34 but always ended w/ static Jul 15 15:03:05 are you running cat /dev/urandom>/dev/dsp after? Jul 15 15:03:08 =p Jul 15 15:03:12 ah, ok. That's an important difference :) Jul 15 15:03:35 heh Jul 15 15:04:01 CoreDump|home: so replaying something whilst its making static noise just continues with static? Jul 15 15:04:28 * CoreDump|home tries Jul 15 15:04:59 nope, in that case the static ends and the sound is played correctly (and ended w/ static again) Jul 15 15:06:32 perhaps the chip is turned off, but the speaker isn't? Jul 15 15:08:49 CoreDump|home: I'll mention this to Liam and see what he says - its in his code rather than mine :) Jul 15 15:08:59 RP: thanks! Jul 15 15:09:37 CoreDump|home: anything in dmesg? Jul 15 15:10:21 soc: DAI[0:0] failed to match clock masters Jul 15 15:10:22 soc: DAI[0:1] failed to match rate Jul 15 15:10:22 soc: DAI[0:2] failed to match rate Jul 15 15:10:22 s Jul 15 15:10:22 CoreDump|home: I don't think its anything major - the codec might just need to be a bit heavier handed when changing DPM states Jul 15 15:10:42 soc: DAI[14:6] failed to match rate Jul 15 15:10:42 soc: DAI[15:0] Match OK Jul 15 15:10:42 s Jul 15 15:10:49 lots of these entries Jul 15 15:10:50 Its a debug kernel so you'll see a lot of general info like that Jul 15 15:11:00 Its just searching for matching bitrates Jul 15 15:11:18 (which we had issues with but have resolved - need to turn off the debugging now) Jul 15 15:11:23 Is glibc broken in .dev? Jul 15 15:12:45 NAbyss: glibc 2.4 compiles fine over here Jul 15 15:14:12 koen: Hmm.. looks like oz-unstable's pulling in glibc-2.3.5.. time to do a bit of digging. Jul 15 15:14:58 shouldn't "inherit autotools" run libtoolize? Jul 15 15:15:04 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? Jul 15 15:15:27 pop wq checking: Playback status: inactive waiting: yes Jul 15 15:15:27 pop wq mute WM8731 Playback Jul 15 15:15:27 pop wq D3 WM8731 Playback Jul 15 15:15:27 [2 Jul 15 15:15:47 checking the timing Jul 15 15:16:42 Ah, I know what it is. Tap the mic when you hear the static ;-) Jul 15 15:17:35 Check your mixer settings ;-) Jul 15 15:18:12 no change ;) Jul 15 15:18:24 i have capture muted Jul 15 15:19:00 also "mute WM8731" and "D3 WM8731" only are printed after the static ends Jul 15 15:21:29 um Jul 15 15:21:45 should libtool symlink to build-arch staging? Jul 15 15:21:56 http://hentges.net/tmp/Memo%20(2).amr this is a sound capture of the bug, can be played w/ mplayer Jul 15 15:22:08 * CoreDump|home dunnos Jul 15 15:22:23 wtf is amr Jul 15 15:22:40 ask sony ericsson Jul 15 15:23:06 403 Forbidden Jul 15 15:23:08 =p Jul 15 15:23:19 err Jul 15 15:23:35 CoreDump|home: Is Output Mixer Line Bypass set? Jul 15 15:23:53 Luke-Jr: fixed Jul 15 15:24:10 mplayer can't play it Jul 15 15:24:16 Output Mixer Line Bypass [Off] Jul 15 15:24:18 mine can Jul 15 15:24:44 Output Mixer Mic Sidetone Switc [Off] Jul 15 15:24:57 CoreDump|home: I know it sounds mental but try turning that on Jul 15 15:24:57 Store DC Offset [Off] Jul 15 15:25:04 (line bypass) Jul 15 15:25:13 same game Jul 15 15:26:02 CoreDump|home: Can you mail me your mixer settings (/etc/asound.state)? Jul 15 15:26:08 sure Jul 15 15:26:13 * RP -> called away - back shortly Jul 15 15:29:18 RP: http://hentges.net/tmp/asound.state Jul 15 15:29:25 re Jul 15 15:29:33 wb Greg2 Jul 15 15:29:48 damn dail-up Jul 15 15:30:16 CoreDump|home: in regard to ts Jul 15 15:30:18 CoreDump|home: i checked again and i do have PR= ?r40? and it has installed r40 Jul 15 15:30:26 sorry for the mix up :) Jul 15 15:30:32 well, that should work then Jul 15 15:31:29 my local tslib is in sync w/ .oz Jul 15 15:32:12 ? Jul 15 15:32:35 meaning I didn't forget to push any changes Jul 15 15:32:48 ok Jul 15 15:33:05 And I built opie-image yesterday and it worked out-of-the-box w/ r40 Jul 15 15:33:55 i did a pull and update yesterday Jul 15 15:34:44 Laibsch: ping :) Jul 15 15:35:05 pong Jul 15 15:35:10 my opie-image won't let me past the calibrate screen :( Jul 15 15:35:20 zecke:pong Jul 15 15:35:55 can you SSH in? Jul 15 15:36:28 i'll have to leave here soon... will try later today Jul 15 15:36:29 pastebin your /etc/profile.d/tslib.sh for me Jul 15 15:36:42 yeah, no hurry Jul 15 15:36:49 heh Jul 15 15:36:50 Laibsch: I'm scared, but your log in the latest error report Jul 15 15:36:56 Laibsch: lacks the source of the error :) Jul 15 15:37:24 Laibsch: so please attach everything from the last 'arm-linux-g++' occurence until the end of the log Jul 15 15:37:25 OK, that backtrace was very long. Jul 15 15:37:35 OK. Jul 15 15:38:11 CoreDump|home: thanks again for your help :) Jul 15 15:38:12 Laibsch: you don't need to attach everything Jul 15 15:38:21 bye all Jul 15 15:38:24 Greg2: you're welcome Jul 15 15:40:14 "Liam is a noob! I?m the real author of ASoC." Jul 15 15:40:17 lol wtf? Jul 15 15:40:30 CoreDump|home: where is that from? Jul 15 15:40:43 A not-yet approved comment on oz.org Jul 15 15:41:08 CoreDump|home: is that comment created by God? Jul 15 15:41:12 Name: Mike Arthur | Jul 15 15:42:18 hehe Jul 15 15:42:33 :) Jul 15 15:42:43 I don't get it Jul 15 15:43:03 Mike Arthur is the summer intern at wolfsson iirc Jul 15 15:43:04 CoreDump|home: From yesterday I know: Mike Arthur is a student working at Wolfson Jul 15 15:43:17 CoreDump|home: Your mixer settings work fine for me :-/ Jul 15 15:43:24 RP: thought so :\ Jul 15 15:43:58 zecke: well, I'm going to approve the comment since it isn't spam. Jul 15 15:44:11 CoreDump|home: yeah, let Liam fight back :) Jul 15 15:44:46 http://openzaurus.org/wordpress/2006/07/12/sound-support-for-poodle26/ Jul 15 15:45:51 It could be argued I was at least a joint author :) Jul 15 15:47:17 ~lart mike Jul 15 15:47:18 * ibot moos at mike Jul 15 15:49:24 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 Jul 15 15:49:37 ~seen mikearthur Jul 15 15:49:38 * RP suspects that line in control Jul 15 15:49:44 mikearthur was last seen on IRC in channel #oe, 1d 2h 18m 53s ago, saying: 'zecke: he will *hopefully* complete touch and battery :D'. Jul 15 15:49:53 interesting Jul 15 15:50:22 I suspect the logic on that control is inverted, just for fun Jul 15 15:50:27 could you send me your working .state? Jul 15 15:50:45 I overwrote it :} Jul 15 15:50:49 =D Jul 15 15:51:18 so Output Mixer Line Bypass [Off] -> ON and reboot Jul 15 15:52:10 well, how do you load your asound.state on reboot? (since zaurusd is AWOL from the poodle images) Jul 15 15:53:32 alsactl restore Jul 15 15:53:53 It only takes effect the first time its run for some settings seemingly, like the speaker Jul 15 15:54:04 * CoreDump|home tries Jul 15 15:59:23 no luck w/ Output Mixer Line Bypass Jul 15 16:05:09 no luck w/ Input Mux [Mic] Jul 15 16:06:12 Its likely this will become easy to debug, once we fix the controls issue :-/ Jul 15 16:06:42 indeed Jul 15 16:19:09 zecke: is "Remember to add `AC_PROG_LIBTOOL' to `configure.ac'. Jul 15 16:19:09 " possibly related? Jul 15 16:19:46 Luke-Jr: probably, but the question is. Where is the libtool version coming from Jul 15 16:22:41 zecke: the libtool from the normal BB for libsigc++ is different from the one if I prepend libtoolize --force to configure Jul 15 16:23:10 Luke-Jr: So sigc++ comes with a custom version of libtool? Jul 15 16:28:05 no clue Jul 15 16:28:15 I just know the current BB doesn't run libtoolize on it Jul 15 16:28:37 and that even if I run it manually in do_configure_prepend, it doesn't fix the problem Jul 15 16:29:10 Luke-Jr: So to summarize Jul 15 16:29:42 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' Jul 15 16:29:59 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?) Jul 15 16:30:25 Whats the best way that i can compile my own programmes with OZ3.5.4/Poodle.. Jul 15 16:30:46 (i need to recompile nsqld.... doesnt work) Jul 15 16:30:49 there's no libtool until after configure executes Jul 15 16:30:53 in sigc++ Jul 15 16:30:57 there is a ltmain Jul 15 16:31:18 sqlite's problem is entirely another matter, unrelated to sigc++ or libtool Jul 15 16:32:00 if I have bitbake run libtoolize on sigc++, the resulting 'libtool' generated by configure is different than otherwise Jul 15 16:32:12 however, the .la still ends up with build-system info Jul 15 16:32:44 Luke-Jr: so the libtool patch in sqlite doesn't have to do with libtool? Jul 15 16:33:00 RickSeymour: setup your OE environment to target that DISTRO/MACHINE and write a BB Jul 15 16:33:25 zecke: I haven't seen anything in sqlite regarding libtool, and the problem with sqlite is not related to libtool Jul 15 16:33:54 Luke-Jr: 'the' problem. I have asked you to look at existing patches to sqlite Jul 15 16:34:03 Luke-Jr: to take that an inspiration to solve your libtool issue Jul 15 16:34:08 as an... Jul 15 16:34:10 oh Jul 15 16:34:26 I thought you were referring to the pointer size problem with sqlite Jul 15 16:35:43 e.g. how is the 'libtool' file called? Jul 15 16:35:58 is it called arm-linux-libtool or just libtool Jul 15 16:36:02 @LIBTOOL@ Jul 15 16:36:14 then check config.log why it thinks x86_64/lib is a good path Jul 15 16:37:06 config.log makes no mention of x86_64-linux/lib Jul 15 16:37:15 and only 'x86_64' with regard to the build system Jul 15 16:38:15 with 1 exception maybe Jul 15 16:38:17 --with-mpfr=/home/luke-jr Jul 15 16:38:24 --with-mpfr=/home/luke-jr/src/oe2005/build.alt/tmp/staging/x86_64-linux Jul 15 16:39:02 libtool is called in practise as /bin/sh ../libtool Jul 15 16:40:25 the mpfr is in a line starting with "Configured with: /home/luke-jr/src/oe2005/build.alt/tmp/work/armv5te-linux/gcc-c Jul 15 16:40:26 ross-4.1.1-r5/gcc-4.1.1/configure" Jul 15 16:40:27 that is bad :) Jul 15 16:40:33 hmm Jul 15 16:40:34 which part? Jul 15 16:40:42 brb Jul 15 16:40:46 this mpfr line Jul 15 16:40:56 oh, so the problem is actually in gcc? Jul 15 16:43:52 might be :) Jul 15 16:44:07 it is not too easy to look into your system from here :) Jul 15 16:44:47 Luke-Jr: a to be cross compiled source should never ever point to the host (for includes and libs) Jul 15 16:45:20 Luke-Jr: if it is calling libtool has 'libtool' we have a bug (maybe a unrelated one) Jul 15 17:15:17 zecke: the config.log mention of mpfr was in the context of GCC's configured arguments Jul 15 17:15:50 zecke: do you have a SSH public key I can grant you access with? Jul 15 17:16:15 I wouldn't have the time to look into it now :( Jul 15 17:16:27 Luke-Jr: I'm about to start a build myself now Jul 15 17:16:36 Luke-Jr: and I assume this behaviour is deterministic Jul 15 17:17:13 zecke: the problem does not occur on x86_32 Jul 15 17:17:22 Luke-Jr: hmm, it should :) Jul 15 17:17:28 Luke-Jr: it might just 'work' Jul 15 17:17:37 right, that's what I mean Jul 15 17:18:49 Luke-Jr: well. I will take a look at the log files Jul 15 17:41:35 03koen 07org.oe.dev * r67295511... 10/packages/linux/ (4 files in 2 dirs): ep93xx-kernel: add derevo20, drop old stuff Jul 15 17:41:39 03koen 07org.oe.dev * rdbdf30b8... 10/packages/linux/ep93xx-kernel/defconfig: ep93xx-kernel: fix defconfig Jul 15 19:08:59 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. Jul 15 19:09:03 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 Jul 15 19:09:07 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 Jul 15 19:09:59 zecke: let me know Jul 15 19:10:39 yes, still compiling away Jul 15 19:10:53 I have a slow machine Jul 15 19:17:20 Why does OE have an almost two years old libvorbis? Jul 15 19:17:56 Actually, it's probably even older. Jul 15 19:20:19 Two and half years, according to Debian changelogs. Jul 15 19:21:15 DataBeaver: because nobody tested newer versions? Jul 15 19:24:11 ERROR: 'BBFILES' while parsing /home/tdb/src/OpenZaurus/org.openembedded.dev/packages/libogg/libogg_1.1.3.bb Jul 15 19:24:18 What's that trying to say? Jul 15 19:24:25 dunno Jul 15 19:30:00 Well, taking weapons of mass destruction to the cache helped. Jul 15 19:37:20 libvorbis 1.1.2 and libogg 1.1.3 compile just fine, now let's see if they work too... Jul 15 19:37:57 DataBeaver, where did you get a Debian changelog for OE? Jul 15 19:38:47 Debian changelog and OE are not related. But I used Debian's changelog to guess the release date for libvorbis 1.0.1. Jul 15 19:39:10 and your Error sounds like you somehow mangled your BBFILES enviroment var after you started a build Jul 15 19:39:22 ah Jul 15 19:40:57 atleast that is my guess. If it happens again echo the variable and see if it matches what it is supposed to be Jul 15 19:41:35 k Jul 15 19:41:53 could be as simple as loging in-out and forgetting to reset the var Jul 15 19:42:42 all depends on your setup Jul 15 19:43:03 Hmh, libvorbis segfaults even now that the version matches what I built my program with. Jul 15 19:44:29 then you must have other bad juju happening Jul 15 19:45:14 disable stripping for it and try to figure out why? Jul 15 19:45:57 Guess I'll have to try that... Jul 15 19:46:20 Another weird thing is that when playing a wav file, top shows about 90% system CPU usage Jul 15 19:47:14 Maybe oprofile will help with that one... Jul 15 19:47:17 why is the weird? Jul 15 19:47:20 that* Jul 15 19:47:46 Because I can't imagine why it would take that much systime. Jul 15 19:48:00 myself i would expect on memory constrained devices to see more cpu usage as the data cannot be buffered as much Jul 15 19:48:06 usertime would be understandable, since my program is compiled without optimizations currently. Jul 15 19:49:11 most OE developers build against tremor (libivorbis) Jul 15 19:49:19 but i suppose you would have to ask one of the guys who do work with sound on actuall behaviour Jul 15 19:49:22 so the regular libvorbis could be broken Jul 15 19:49:27 hm. Jul 15 19:54:34 That presents the problem of libivorbis not being available for Debian. Jul 15 19:56:53 And about the CPU usage... On my PCs, the same program (unoptimized) takes barely any CPU time at all, so something's fishy. Jul 15 19:57:14 DataBeaver: your PC has a floating point unit? Jul 15 19:58:03 heh Jul 15 19:58:19 DataBeaver: what codec does the WAV file contain? Jul 15 19:58:31 Plain PCM Jul 15 19:58:46 * Luke-Jr doesn't know whether PCM needs a FPU Jul 15 19:58:50 Hmh, the ARM not having an FPU could explain a thing or two... Jul 15 19:58:57 * emte had forgotten about the FPU issue with audio Jul 15 19:59:04 Is libivorbis the one that doesn't use floats? Jul 15 20:00:09 libi(nteger)vorbis Jul 15 20:00:54 My code currently uses some floating-point computation even when none is needed Jul 15 20:01:08 why? Jul 15 20:01:27 'cause it made the design simpler and is of no concern on normal PCs? Jul 15 20:01:43 So does the kernel emulate the FPU then and makes things slow? Jul 15 20:01:44 is floating point math any different from integer math on systems with a FPU? Jul 15 20:01:45 in speed Jul 15 20:01:51 yes Jul 15 20:02:02 but systems are so fast now its not very moticable Jul 15 20:02:03 DataBeaver: either that or the compiler uses software fp Jul 15 20:02:04 I think the difference is pretty minimal these days Jul 15 20:02:13 noticable* Jul 15 20:02:15 emte: floating point is slightly slower? Jul 15 20:02:20 or faster? Jul 15 20:02:35 except in heavy math computations, and this is why the AS/400 etc still exist Jul 15 20:02:37 Slightly slower Jul 15 20:02:52 And then there's the special cases of NaNs and Infs which are pretty damn slow Jul 15 20:03:04 Okay then... I'll modify my code so it doesn't use floats... Jul 15 20:03:28 Float variables are typically also larger that 32bit ints, so using floats extensivile has a larger memory cost Jul 15 20:03:46 IEEE float is 32-bit, double is 64-bit Jul 15 20:04:07 IEEE are unsigned i belive are they not? Jul 15 20:04:10 but anyway, PCM shouldn't need a FPU, should it? Jul 15 20:04:11 err Jul 15 20:04:15 floating point math Jul 15 20:04:18 IEEE floats are signed Jul 15 20:04:26 I've never heard of unsigned floats Jul 15 20:04:35 * Luke-Jr either Jul 15 20:04:54 Luke-Jr: Nope. In this case I could pretty much just copy the data from the file to ALSA. Jul 15 20:04:58 i use them, but its to handle register issues Jul 15 20:05:17 so the question remains why his PCM WAV file uses 99% CPU Jul 15 20:05:17 allows full 32 bit access without losing a bit for sign Jul 15 20:05:25 What device supports unsigned floats? Jul 15 20:05:31 all Jul 15 20:05:37 really? Jul 15 20:05:38 what compiler does? Jul 15 20:05:47 most i belive Jul 15 20:05:52 or does the 'unsigned' prefix apply to everything? Jul 15 20:05:53 some one considers merging? Jul 15 20:06:03 certainly have never seen 'ufloat' Jul 15 20:06:05 or udouble Jul 15 20:06:07 C++ at least defines floats to be signed. Jul 15 20:06:23 they default signed for obvious reasons Jul 15 20:06:47 but if you know you will never have negative numbers or handle it externally then you can use unsigned Jul 15 20:08:42 but most PC people never use it unless they are optimising code Jul 15 20:09:15 * emte wonders where i put those CAN chips Jul 15 20:13:20 grr Jul 15 20:13:32 my wife absolutely refuses to let me teach her the difference between signed and unsigned Jul 15 20:13:40 -.- Jul 15 20:13:58 heh Jul 15 20:14:08 Not very computer-oriented, is she? Jul 15 20:14:25 yah, she doesn't know how handy that info will be Jul 15 20:14:39 lol Jul 15 20:14:42 its easy Jul 15 20:14:50 1+1 vs 1+1.1 Jul 15 20:15:26 DataBeaver: she was in her high school's "computer elite" group thing Jul 15 20:15:31 or if its unsigned everything is positive Jul 15 20:16:09 anyone know where i put my black wire? Jul 15 20:16:12 yes Jul 15 20:16:15 but I'm not telling Jul 15 20:16:30 lol Jul 15 20:17:08 until I have a working image Jul 15 20:17:08 =p Jul 15 20:19:10 i'll give you a working image :P Jul 15 20:20:37 well i found my wire Jul 15 20:20:49 now to find my stash of wirewrap sockets Jul 15 20:20:56 emte: I want to build it tho =p Jul 15 20:26:36 Okay, let's see if that works now... Jul 15 20:27:31 Seems to work. Jul 15 20:28:15 And it seems to use the int stuff too. Jul 15 20:28:22 Now to test it on my Z... Jul 15 20:33:35 Hm, doesn't quite work... Jul 15 20:44:18 * Luke-Jr ponders just using OZ and forgetting about the build problems Jul 15 20:52:21 Grr. It writes some amount of data to ALSA and then gets stuck with EAGAIN. Jul 15 20:57:57 dmesg shows a lot of lines like "soc: DAI[23:4] failed to match rate" Jul 15 20:58:21 And finalle "Match OK" and after that "spurious IRQ for DMA channel 0" Jul 15 20:59:01 mp3blaster doesn't generate that spurious interrupt. Jul 15 21:01:00 I wonder what I'm doing differently... Jul 15 21:04:02 Huh. Apparently mp3blaster doesn't use ALSA at all. Jul 15 21:05:51 In other news, has this Werner Shulte fellow (http://www.uv-ac.de/openembedded ) been invited to contribute to the OE wiki? Jul 15 21:07:14 yes Jul 15 21:07:28 he seems to be busy at work, I haven't seen him in ages Jul 15 21:07:31 ~seen uv1 Jul 15 21:07:34 ~seen uv Jul 15 21:07:34 uv1 was last seen on IRC in channel #oe, 49d 13h 3m 39s ago, saying: 'RP: Thanks, will try ...'. Jul 15 21:07:36 uv <~sc@p50924353.dip0.t-ipconnect.de> was last seen on IRC in channel #oe, 545d 2h 24m 17s ago, saying: 'By'. Jul 15 21:07:41 whoa Jul 15 21:08:10 * Kerwood_ understands Jul 15 22:12:14 are there other public trees than the OE tree? i.e. third party sources of BBPATH-compatible trees? Jul 15 22:12:57 zwelch: technically familiar tree is split Jul 15 22:13:59 zwelch: are you counting the multiple branches in the monotone repo? :P Jul 15 22:14:09 also, the repo openedhand.com uses is publicly accessible Jul 15 22:14:11 kergoth: not really ;) Jul 15 22:14:14 their distro, "poky" Jul 15 22:14:20 minimal repo for just that Jul 15 22:14:47 for a real example, i have my tree here: http://svn.minisplat.org/svn/src/trunk/build.d/dist/oe/ Jul 15 22:15:36 zwelch: http://svn.o-hand.com/repos/poky/trunk Jul 15 22:15:42 ~poky Jul 15 22:15:44 [poky] http://projects.o-hand.com/poky, or a subset of OpenEmbedded, created by o-hand.com to testdrive some of their technology Jul 15 22:16:02 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 ;) ) Jul 15 22:17:06 BBPATH doesnt find bb files, its for classes/conf. you'd use collections and bbfiles for the packages themselves Jul 15 22:17:13 but yes, theres no need to maintain everything in one repo Jul 15 22:17:31 so, i would guess that i am not the first person to suggest splitting the main OE repo into several smaller package repositories Jul 15 22:17:34 BB Collections can help as well Jul 15 22:17:44 * zwelch dons his asbestos suit, just in case Jul 15 22:17:56 zwelch: the problem becomes, where do you split? Jul 15 22:18:21 kergoth: yes, that becomes the "i believe" part of the discussion; there is no "right" answer Jul 15 22:18:33 zwelch: what we might do one time. Is creating 'views' of the MetaData Jul 15 22:18:56 zwelch: e.g. using test results to give you a known working copy for a specific task Jul 15 22:18:57 zwelch: i'd argue that its better to have one repository than to start throwing around completely arbitrary boundaries.. Jul 15 22:18:57 zecke: i am interested in these collection things, but i don't recall reading much about them in the docs Jul 15 22:19:29 kergoth: i agree for the most part; there are pros and cons of each approach, but intertia has a big play in it too Jul 15 22:19:35 zwelch: see the BitBake manual. Jul 15 22:19:51 zwelch: e.g BB Collections help you to ease 'forks' Jul 15 22:19:56 zwelch: optimally, what i'd want is more of a split than is currently possible with bitbake Jul 15 22:20:07 zwelch: rewrite bits one by one while allowing you to easily merge Jul 15 22:20:12 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 Jul 15 22:20:22 heh Jul 15 22:21:06 * zecke can't believe to have set EDITOR to emacs :} Jul 15 22:21:40 kergoth: i agree with you there Jul 15 22:22:19 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 Jul 15 22:22:55 back to work... Jul 15 22:23:01 as much as possible, it should build on top of - but separately from - the main OE repo Jul 15 22:23:07 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 Jul 15 22:23:46 i'd still settle for a Core, GPE, Opie, QTE, X11, and Optional repos Jul 15 22:23:59 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 Jul 15 22:25:16 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 Jul 15 22:25:36 in the main repo, i'd only want a conf file that could "include " :) Jul 15 22:25:50 i.e. figure out to download the additional repos automatically Jul 15 22:26:10 kergoth: does any of that make sense to you? Jul 15 22:26:22 bitbake isnt that smart yet, we have big hopes for BB-ng from kergoth :P Jul 15 22:27:18 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) Jul 15 22:27:20 if bitbake starts using the sqlite backend then you could walk your intended build to get files and generate graphs Jul 15 22:27:57 it can generate graphs now as well... :) Jul 15 22:28:00 well, you don't need sqlite to do that; though, i admit you might need it to do it in a timely manner ;) Jul 15 22:28:23 zecke, yeah but not the kind needed for it to be smart Jul 15 22:29:35 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 Jul 15 22:29:54 I'm too tired to keep up forking between irc and work Jul 15 22:29:55 later pals Jul 15 22:29:59 night Zero_Chaos Jul 15 22:30:03 lol Jul 15 22:30:08 tab not fast enough Jul 15 22:31:10 * emte needs to invest in a better wirewrap tool Jul 15 22:32:43 but yeah i agrre with the package overlap posibility Jul 15 22:32:52 agree* Jul 15 22:36:59 wasn't koen's google project about making it better to use? Jul 15 22:37:06 it=monotone/bb Jul 15 22:37:48 i doubt OE will get any support from google any time soon Jul 15 22:38:05 unless someone files for nonprofit status Jul 15 22:38:50 http://code.google.com/soc/handhelds/appinfo.html?csaid=CED12F0DF30CA6C2 Jul 15 22:38:55 thejapa: no, his project is to make staging packaged and managed Jul 15 22:39:02 oh Jul 15 22:39:12 why the heck is it under handhelds.org? Jul 15 22:39:14 jesus Jul 15 22:40:01 i guess that was before the openembedded.org Jul 15 22:40:09 because hh.o is a registered nonprofit organization Jul 15 22:41:12 thejapa: openembedded.org has been around for years. it happened to be -hosted- by handhelds.org, but thats all Jul 15 22:41:15 ah well Jul 15 22:41:43 oe.o also has no administrative body Jul 15 22:42:17 hmm, it will take lots of time to understand all these things :) Jul 15 22:42:43 so technically oe.o doesnt exist Jul 15 22:42:52 you don't need a formal administrative body to do SoC :-) Jul 15 22:43:30 but OTOH, google doesn't want to sponsor multiple projects in the same area, so there are lots of umbrella-y setups for SoC Jul 15 22:43:55 they should call that section embedded linux then, and leave it at that Jul 15 22:44:01 yeah, there are evolution projects in ubuntu Jul 15 22:44:06 opensync in kde Jul 15 22:45:02 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 Jul 15 22:46:22 infrastructure? Jul 15 22:47:17 not sure on that one myself Jul 15 22:47:34 nmap the last two years did SoC with 10-15 students and 1 admin/mentor Jul 15 22:47:38 fyodor is a busy guy :-) Jul 15 22:47:40 imo, hh.org is the portal for ipaq users, so it gets all popularity, that makes it easier to get chosen by google. Jul 15 22:47:59 i am not sure that is correct Jul 15 22:48:03 the actual way google chose projects though is all mysterious and random, so *Shrug* Jul 15 22:48:07 i disagree, i think oe just hasnt been marketed well. Jul 15 22:48:10 there are FAR more zaurii devs than ipaq Jul 15 22:48:35 in brazil you can count the zaurii in one president's hand i guess :) Jul 15 22:48:43 (our president has 4 fingers) Jul 15 22:48:52 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. Jul 15 22:49:00 dont most people on each nad? Jul 15 22:49:03 hand* Jul 15 22:49:08 RP: njs just contradicted you on that, so.. Jul 15 22:49:10 * kergoth shrugs Jul 15 22:49:20 oh, umm, "done it before" was an automatic qualification this year Jul 15 22:49:35 kergoth: OE hasn't had the marketing which does put us at a disadvantage for things like this Jul 15 22:49:48 kergoth: not on every point he didn't Jul 15 22:49:54 mind if I ask, what happened to last year students? disappeared? Jul 15 22:50:01 (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) Jul 15 22:50:29 thejapa, gremilin still pops in and does work Jul 15 22:50:34 kergoth: re splitting "distro specific modification", I have plans for such an architecture for a package manager planned Jul 15 22:50:37 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 Jul 15 22:50:52 Luke-Jr: have a wiki page on it somewhere? Jul 15 22:51:16 kergoth: not really, just notes Jul 15 22:51:24 kergoth: yah; clearly the main reason that oe didn't get into SoC is that nobody filed an application. Jul 15 22:51:24 i can tell you that enlightenment has had project presented in the last few and always been turned down Jul 15 22:51:28 the idea is based on Portage's USE flags, except making them modular Jul 15 22:51:28 hehe Jul 15 22:52:22 kergoth: You've also ignored my people point - we don't have the people Jul 15 22:52:23 Luke-Jr, you aware that the portage-c people were contected at one point? Jul 15 22:52:36 emte: contacted about? Jul 15 22:52:55 bitbake i belive, kergoth could probably tell you the outcome Jul 15 22:53:17 but what about them? I need a verb of some sort =p Jul 15 22:54:13 kergoth: actually, OE can handle something similar-- it has the ability to insert steps and such Jul 15 22:54:44 kergoth: project-specific changes could be a new BB built on the vanilla one, but inserting a customize step Jul 15 22:55:02 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 Jul 15 22:58:01 you mean more-or-less recipe plugins? Jul 15 22:58:10 eg, a plugin could be created to handle Gentoo's ebuilds? Jul 15 22:59:01 thatd be the idea, though ebuilds are problematic since they're not directly parsed Jul 15 23:00:19 why not modularize also the execution of recipes? Jul 15 23:00:47 so a plugin to use RPM (for example) as a 'receipe'/source might be possible? Jul 15 23:01:05 bitbake already supports rpm i belive Jul 15 23:01:07 in which case, a ebuild plugin could probably be a patch or wrapper to Gentoo's Portage programs Jul 15 23:01:14 it does, bitbake supports src.rpm Jul 15 23:01:20 emte: as a recipe? Jul 15 23:01:30 yes, you can use a src.rpm directly Jul 15 23:01:36 it extracts the metadata and converts it to bitbake's Jul 15 23:01:43 then it can emit a binary rpm or ipk or whatever Jul 15 23:01:51 what about a binary RPM? ;) Jul 15 23:02:13 (yes, it'd be pointless-- but as a test for abstraction) Jul 15 23:02:24 an rpm is an rpm from the metadata side, it could parse it fine but would have no recipes to execute Jul 15 23:02:29 that poses problems for obvious reasons Jul 15 23:02:39 you'd have to have a seperate .bbclass to do the legwork of ripping out the binaries for the steps Jul 15 23:03:13 well, for a binary RPM there'd probably only be an unpack step before package/populate Jul 15 23:04:20 yeah, bitbake could do that today. not well, or cleanly, but.. ;) Jul 15 23:04:30 hm Jul 15 23:04:40 following recipes is such a common thing though, its used everywhere, even in make and scons Jul 15 23:04:48 makes sense to have a capable flexible backend library Jul 15 23:04:55 where are the package/populate steps defined anyway? Not at the receipe level, I presume Jul 15 23:05:15 Luke-Jr: base.bbclass for .bb files, base_srcrpm or somesuch.bbclass for src.rpm Jul 15 23:05:23 thats the base steps Jul 15 23:05:30 i think packaging is in package.bbclass and package_ipk.bbclass, etc. Jul 15 23:05:39 but i've been away, so that couldve changed recently and i wouldnt know Jul 15 23:05:43 so a BB could delete the package step to prevent it from being packaged? Jul 15 23:06:22 * Luke-Jr is pondering using BitBake for a desktop OS Jul 15 23:06:40 pretty sure thatd work, it depends on whether package.bbclass gets pulled in before parsing the .bb or after, i Jul 15 23:06:54 but you could remove it from INHERITS if after, so yes, you could one way or another afaik Jul 15 23:07:20 i want a debianish distro using rpm for the binary packages and a tool like bitbake/oe to build those packages for installation Jul 15 23:07:23 one day Jul 15 23:07:38 why RPM? Jul 15 23:07:47 the CPUS rpm i hope Jul 15 23:07:51 CUPS* Jul 15 23:08:04 personal preference, i like the way rpm does things more than i like the way dpkg does things Jul 15 23:08:13 could BitBake handle the *installation* (merge) of the binary RPM to the base system? Jul 15 23:08:29 the preference on the source building side of the format is obviously leaning towards rpm, as .spec makes sense, debian's 'rules' is crap Jul 15 23:09:18 Luke-Jr: hmm, perhaps, but you might run into issues between build order vs installation order Jul 15 23:09:27 not sure, they've changed the depends handling recently Jul 15 23:09:28 kergoth: eh? Jul 15 23:09:41 oh yeah... the new depend handling doesn't work :( Jul 15 23:09:46 would need to fix that for serious use Jul 15 23:09:55 not to mention we need versioned deps and all that Jul 15 23:09:58 currently its ewak Jul 15 23:09:59 weak Jul 15 23:10:38 right, BitBake needs everything it ripped out back when it was portage-based Jul 15 23:10:53 USE flag equivalents, for example Jul 15 23:11:14 thats a tough one Jul 15 23:11:21 is it? Jul 15 23:11:22 if you want to have a sane binary distro based on it, anyway Jul 15 23:11:35 well, I'm not interested in a binary distro ;) Jul 15 23:11:35 since it isnt easy to distinguish a binary built one way vs one built another, is there? Jul 15 23:11:42 you'd have ot encode USE into the binary packages and such Jul 15 23:11:43 yes Jul 15 23:12:02 so long as you don't rely on a human identifying the packages Jul 15 23:12:03 ah, well yes, use without worrying about that isnt troublesome Jul 15 23:12:13 but USE is extremely limited, i dont like the flat namespace myself Jul 15 23:12:26 well, I use "USE" as a generic term here Jul 15 23:12:29 * kergoth nods Jul 15 23:12:31 not a specific implementation Jul 15 23:12:33 i thought binary diff/identification tools existed Jul 15 23:12:36 even Gentoo has left the flat namespace Jul 15 23:12:41 they do, but that wouldnt be useful here Jul 15 23:12:43 ah good Jul 15 23:12:45 finally :) Jul 15 23:12:52 now they have USE, LINGUAS, VIDEO_CARDS, etc Jul 15 23:13:03 Luke-Jr: Why doesn't the new depends handling work? Jul 15 23:13:06 which are implemented as linguas_* USE flags within ebuilds Jul 15 23:13:07 not unlike OE today then. we have IMAGE_LINGUAS, etc Jul 15 23:13:13 just a bit fancier Jul 15 23:13:23 RP: no idea; it seemingly randomly decides to skip dependencies for me Jul 15 23:13:50 RP: on *-image anyhow Jul 15 23:13:52 and tasks Jul 15 23:13:53 and such Jul 15 23:13:55 Trust me, its not random and it usually has good reason ;-) Jul 15 23:14:04 Not that I can determine, though Jul 15 23:14:13 here's the simplest case... Jul 15 23:14:22 I start with a empty 'tmp' Jul 15 23:14:32 I tell it to build gpe-image Jul 15 23:14:42 03freyther 07org.oe.dev * rf74c5b28... 10/conf/distro/openzaurus-unstable.conf: (log message trimmed) Jul 15 23:14:42 conf/distro/openzaurus-unstable.conf: binutils 2.16 is preferred Jul 15 23:14:42 Prefer binutils 2.16 as this is the last working version working Jul 15 23:14:42 with glibc 2.3. Use that version for binutils-cross as well. This Jul 15 23:14:42 should avoid all occurences of the '__bind' error when compiling Jul 15 23:14:43 glibc. Jul 15 23:14:43 it begins building deps Jul 15 23:14:45 For the future we need a better way to select matching versions of Jul 15 23:14:48 errors somewhere Jul 15 23:15:00 and when I tell it to 'build gpe-image' again, it skips deps and goes right to gpe-image Jul 15 23:15:43 I had that happen at least twice Jul 15 23:16:05 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 Jul 15 23:16:29 RP: that would be a problem if it builds dependencies AFTER the package itself... Jul 15 23:17:08 but that also wouldn't explain why sometimes it will suddenly notice the dependencies again Jul 15 23:17:37 I can't wait to rewrite the dependency handling code ;-) Jul 15 23:17:41 heh Jul 15 23:17:51 glad it's planned =p Jul 15 23:18:09 Its started as it happens ;-) Jul 15 23:18:15 just wish I could build a OZ-unstable gpe-image Jul 15 23:18:25 right now Jul 15 23:18:50 I should have used one of my x86_32 systems for OE... too many problems with 64-bit and OE Jul 15 23:20:47 nite Jul 15 23:25:59 'night all Jul 15 23:27:21 night Jul 15 23:28:26 Funny, even without floats my program still takes 30% CPU. Jul 15 23:28:35 Most of it systime. Jul 15 23:38:58 DataBeaver, what is your cpu freq? Jul 15 23:39:09 and what is the bitrate of the file? Jul 15 23:40:02 and 30% is quite a saving, down from 90% Jul 15 23:45:13 The do_rootfs stage fails when I attempt to bitbake gpe-image. The error is "Couldnt kill old gunzip process", but I've found no corruption with the package it fails on. http://www.rafb.net/paste/results/KS81qD82.html http://www.rafb.net/paste/results/xZ6Cfq34.html There's a SIGCHLD, then immediately after that it tries to kill it. I've tried rebuilding glibc but it didn't fix my problem. I'm building in org.openembedded.oz354x, any suggestions? Jul 15 23:45:13 416MHz, and the file is 44.1kHz S16 stereo Jul 15 23:53:00 I tested with time and it took 4sec of usertime and 1:03 of systime for a song of 3:55 Jul 16 00:09:33 Dropping samplerate to 22kHz halved the CPU usage as well Jul 16 00:09:50 Only 15% now Jul 16 00:10:15 Now if I just figured a nice way to compile this against libvorbisi... Jul 16 00:10:32 But I guess that'll wait 'till tomorrow. Jul 16 00:12:20 well dropping the rate by half or switching it to mono would cut the usage in half Jul 16 00:13:40 as for your 5.03 for a 4 second clip, i am guessing initial buffering and preprocessing Jul 16 00:14:15 as well as less that optimal bus data transfer Jul 16 00:14:19 than* Jul 16 00:15:17 but upto 30% cpu seems reasonable for CD quality audio Jul 16 00:20:00 Switching to mono had no noticeable effect Jul 16 00:21:43 Anyways, bedtime. Good night. Jul 16 01:24:51 Luke-Jr: I see that problem if I'm running bitbake interactive. If I restart bitbake -i, it seems to be OK then -- at least in the case I remember. Jul 16 01:33:02 cbrake_away: ? **** ENDING LOGGING AT Sun Jul 16 02:59:57 2006