**** BEGIN LOGGING AT Sun Jan 22 02:59:57 2012 Jan 22 05:36:25 Weiss: the OpenMooCow git repository appears to be broken Jan 22 05:46:14 anyone know whats going on with git.openmoko.org? Jan 22 06:19:42 pabs3: ugh, weird Jan 22 06:21:29 pabs3: seems to just be the gitweb view, not the actual repository..? Jan 22 06:21:53 Weiss: both, I got the origin/master branch deleted when I pulled Jan 22 06:27:52 hmm, git-daemon seems to have taken a random disliking to openmoocow.git Jan 22 06:28:08 clone via SSH works Jan 22 06:28:20 and the repository itself seems to be in order Jan 22 06:42:52 Weiss: seems fixed now, thanks Jan 22 06:43:53 yeah Jan 22 06:44:12 I had a bad umask set in my gitolite config, so git-daemon and the web server couldn't read it Jan 22 06:46:02 ah Jan 22 06:46:58 I think two of the last three patches have already been applied in April last year..? Jan 22 06:59:41 hmm Jan 22 08:19:12 PaulFertser: hey this is answer of stefan schimdt > Jan 22 08:19:13 The number of shown partitions is hardcoded atm to DFU_NUM_ALTERNATES Jan 22 08:19:13 which is set to 6. So you last partition does not get shown increment Jan 22 08:19:14 it to seven in your board config and re-compile your u-boot and test Jan 22 08:19:14 again. Jan 22 11:23:34 heyho Jan 22 11:27:49 hi morphis Jan 22 11:40:35 GNUtoo: ping Jan 22 11:57:47 morphis, pong Jan 22 12:08:13 GNUtoo: you reported audio problems with the Nexus S but didn't explained which kind of problems you got Jan 22 12:08:25 morphis, it blocks and doesn't play Jan 22 12:08:31 from lastest image Jan 22 12:08:40 which image? Jan 22 12:08:45 shr-image Jan 22 12:08:55 does it work on other images? Jan 22 12:09:00 like from yesterday? Jan 22 12:09:08 I have the aurora-image here only and after flash and first boot it plays audio with aplay with back speaker Jan 22 12:09:17 ok Jan 22 12:09:22 from yesterday? Jan 22 12:28:20 morphis, I'll build an aurora image but it'll take quite some time Jan 22 12:28:39 each time that I change machine it tries to rebuild the toolchain and fails Jan 22 12:28:50 the solution is clean the toolchain Jan 22 12:28:58 which means that it has to be rebuilt Jan 22 12:29:09 morphis, also I sent you a mail about fsoaudiod license Jan 22 12:29:21 I need to upgrade it to GPL else we have to drop gta04 Jan 22 12:29:39 which may not be the best thing to do (drop gta04) Jan 22 12:29:52 basically it's for the forwarder Jan 22 12:29:57 mickeyl, is ok with it Jan 22 12:30:02 but you're the maintainer Jan 22 12:31:18 hi gnutoo! does audio calling work on gta04 with your latest changes? Jan 22 12:31:45 on my device it works but it's not very well tested Jan 22 12:31:56 I have to do a real test call Jan 22 12:31:57 rather than calling myself Jan 22 12:32:02 to see if there is any echo left Jan 22 12:32:10 also, Jan 22 12:32:19 just building an image won't get you the lastest changes Jan 22 12:32:36 you need to use my branch for alsaloop Jan 22 12:32:39 i'll need newer fsoaudio, right? Jan 22 12:32:43 ah ok Jan 22 12:32:53 it's awaiting morphis response to merge it Jan 22 12:32:58 ok Jan 22 12:32:59 else it's not GPL compliant Jan 22 12:33:14 because we need to upgrade fsoaudiod to GPL Jan 22 12:33:18 i see Jan 22 12:33:20 because alsaloop is GPL Jan 22 12:33:27 fsoaudiod is currently LGPL Jan 22 12:34:12 I need to find someone to make a real call Jan 22 12:34:16 maybe paulk-desktop ? Jan 22 12:34:27 ok. i'll test your branch once i find some time... I'm pretty busy with university at the moment, though Jan 22 12:34:36 ok Jan 22 12:34:42 GNUtoo: I got no mail Jan 22 12:34:50 btw: do you go to FOSDEM? Jan 22 12:35:01 GNUtoo yeah, why not :) Jan 22 12:35:11 mickeyl: ping Jan 22 12:35:43 GNUtoo: like GTA04 to nexus s? Jan 22 12:35:49 morphis, http://lists.linuxtogo.org/pipermail/smartphones-userland/2012-January/003110.html Jan 22 12:35:58 paulk-desktop, yes Jan 22 12:36:03 ok Jan 22 12:36:09 altough I prefer to do it after eating Jan 22 12:36:13 alright Jan 22 12:36:19 let me know when you're going to try Jan 22 12:36:28 ok thanks a lot Jan 22 12:39:14 GNUtoo: I am fine with chaging license to GPL Jan 22 12:39:20 will do this today Jan 22 12:41:39 nice thanks a lot Jan 22 12:41:45 I'll respond to the nexus S status Jan 22 12:43:06 btw I did a quick porting guide for alsa scenarios Jan 22 12:43:12 as no one seem to understand it Jan 22 12:43:13 http://wiki.freesmartphone.org/index.php/AlsaScenarios Jan 22 12:45:18 GNUtoo: great! Jan 22 12:45:26 gnutoo, this is very appreciated. i never understood the details! Jan 22 13:15:53 morphis, do you know what DAPM is btw? Jan 22 13:16:05 I'm not sure keeping the CODEC open is a good idea Jan 22 13:16:16 maybe it doesn't do any harm Jan 22 13:16:27 but maybe it consumes more power Jan 22 13:16:47 anyway I'm building aurora-image Jan 22 13:16:54 along with the usuall stuff I build Jan 22 13:16:59 so we'll see Jan 22 13:17:03 how usable is aurora now btw? Jan 22 13:17:12 no idea Jan 22 13:17:15 ok Jan 22 13:17:18 when did you try it? Jan 22 13:17:27 what features do you lack? Jan 22 13:17:48 paulk-desktop, note that aurora transform your smarphone in a feature-phone Jan 22 13:17:58 all apps that you can run have to be in aurora Jan 22 13:18:00 it was on nexus s months ago Jan 22 13:18:02 that's how it works Jan 22 13:18:08 I was stuck at some point Jan 22 13:18:08 ok Jan 22 13:18:26 so for instance if you want to run navit for instance you'll have to port/rewrite it Jan 22 13:18:44 ah? Jan 22 13:18:48 it's not running on Xorg? Jan 22 13:18:55 it is Jan 22 13:18:57 but still Jan 22 13:19:10 it doesn't permit you to run arbitrary apps Jan 22 13:19:15 ah ok Jan 22 13:19:32 altough it may work better than SHR on the nexus S Jan 22 13:19:49 since I didn't do a lot for the nexus S recently on SHR side Jan 22 13:20:08 ok Jan 22 13:30:36 morphis, what's the way to implement quirks with devices that have ifconfig+rfkill? Jan 22 13:34:27 ouch I broke fsodeviced Jan 22 13:34:28 sorry Jan 22 13:34:38 I tested within devshell only Jan 22 13:37:34 GNUtoo: of course keeping any device open will keep it powered and thus consume "lots" of power for nothing Jan 22 13:37:47 ok Jan 22 13:38:42 ln -sf alsa-3.2 /home/gnutoo/embedded/oe/oe-core/oetmps/shr/work/crespo-oe-linux-gnueabi/fsodeviced/fsodeviced-2_0.9.4+gitr12+a1622efddcfc79eee137308c4c66a4e754e02e53-r6.25/image/etc/freesmartphone/conf/`basename $PWD`/alsa-default Jan 22 13:38:42 ln: creating symbolic link `/home/gnutoo/embedded/oe/oe-core/oetmps/shr/work/crespo-oe-linux-gnueabi/fsodeviced/fsodeviced-2_0.9.4+gitr12+a1622efddcfc79eee137308c4c66a4e754e02e53-r6.25/image/etc/freesmartphone/conf/GTA04/alsa-default': No such file or directory Jan 22 13:38:46 here's my error Jan 22 13:40:29 it's created by that: Jan 22 13:40:30 ln -sf alsa-3.2 $(DESTDIR)/etc/freesmartphone/conf/$(THISDIR)/alsa-default Jan 22 13:40:54 which I took from om-gta02: Jan 22 13:40:55 ln -sf alsa-2.6.39 $(DESTDIR)/etc/freesmartphone/conf/$(THISDIR)/alsa-default Jan 22 13:42:12 ah ok GTA04 is not there Jan 22 13:42:33 I'll look how to ship gta04 Jan 22 13:48:49 mrmoku, ping Jan 22 13:50:01 I don't understand why the configurations are not copied anymore Jan 22 13:52:19 ahhh Jan 22 13:52:22 I think I got it Jan 22 13:52:26 confdir = $(sysconfdir)/freesmartphone/conf/openmoko_gta/alsa-2.6.39 Jan 22 13:52:32 in gta04 stuff Jan 22 14:04:23 GNUtoo: pong Jan 22 14:04:29 GNUtoo: yeah, call it alsa-default instead Jan 22 14:04:36 ah? Jan 22 14:04:52 hmm... or alsa-gta04 Jan 22 14:05:00 as the that's the sound-cards name Jan 22 14:05:07 I still didn't find out why it's broken Jan 22 14:05:11 which is what fsodeviced is looking for Jan 22 14:05:38 -confdir = $(sysconfdir)/freesmartphone/conf/openmoko_gta/alsa-2.6.39 Jan 22 14:05:38 +confdir = $(sysconfdir)/freesmartphone/conf/openmoko_gta/alsa-3.2 Jan 22 14:05:40 didn't fix it Jan 22 14:05:51 maybe I should push and retry a build from scratch Jan 22 14:05:57 of fsodeviced Jan 22 14:06:05 sure did not fix it Jan 22 14:06:14 fsodeviced is looking for alsa-$(cardname) Jan 22 14:06:27 on gta02 we have a link for the appropriate kernel Jan 22 14:06:34 linking to alsa-default Jan 22 14:06:50 ln -sf alsa-3.2 $(DESTDIR)/etc/freesmartphone/conf/$(THISDIR)/alsa-default Jan 22 14:07:08 I don't understand in what context $(cardname) is called Jan 22 14:07:12 ok, and in case of gta04 default might be wrong Jan 22 14:07:16 I'm talking about run_do_install Jan 22 14:08:06 GNUtoo: var soundcard = alsaconf.stringValue( "alsa", "cardname", "default" ); Jan 22 14:08:09 dataPath = FsoFramework.Utility.machineConfigurationDir() + @"/alsa-$soundcard"; Jan 22 14:08:17 ah ok Jan 22 14:08:20 but that's at runtime Jan 22 14:08:24 sure Jan 22 14:08:25 I'm talking about do_install Jan 22 14:08:30 do_install is broken Jan 22 14:09:10 you don't need that linking Jan 22 14:09:24 that is only needed for incompatible scenarios on different kernels Jan 22 14:09:41 yes but we have 2.6.32 and may have other kenrels in the future Jan 22 14:09:51 so that's why I did it like that Jan 22 14:09:57 I'll revert the linking then Jan 22 14:12:14 I think I found the problem Jan 22 14:12:19 what should I do then now Jan 22 14:12:40 commit? Jan 22 14:12:47 I could retry then if it still gives me busy Jan 22 14:12:58 ? Jan 22 14:13:09 yes but commit which version Jan 22 14:13:13 the fix with the linking Jan 22 14:13:19 or should I remove the linking Jan 22 14:13:32 I don't care ;) Jan 22 14:13:35 ok Jan 22 14:13:51 then I'll keep the linking Jan 22 14:14:01 I hope to not need that stuff in fsodeviced anymore when we hit an incompatible kernel :-) Jan 22 14:16:53 freesmartphone.org: 03GNUtoo 07cornucopia * r9b72e06384a4 10/fsodeviced/conf/GTA04/alsa-3.2/Makefile.am: Jan 22 14:16:53 freesmartphone.org: fsodeviced: GTA04 config: fix installation of the config Jan 22 14:16:53 freesmartphone.org: Without that fix we have(during the installation): Jan 22 14:16:53 freesmartphone.org: ln: creating symbolic link `.../image/etc/freesmartphone/conf/GTA04/alsa-default': No such file or directory Jan 22 14:16:54 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jan 22 14:17:42 mrmoku, note that there will be incompatible kernels in the future Jan 22 14:17:51 since the kenrel hacker didn't mask the useless controls yet Jan 22 14:24:29 GNUtoo: hmm, yeah right... Jan 22 14:24:52 now we need to solve the power consumation problem Jan 22 14:25:04 basically rfkill is not used Jan 22 14:25:14 because it conflicts with powercontrol_ifconfig Jan 22 14:25:19 and it also segfaults Jan 22 14:25:27 according to you Jan 22 14:25:36 in what conditions does it segfault? Jan 22 14:28:32 do you want to do it? Jan 22 14:55:26 morphis: | No package 'dconf-qt' found Jan 22 14:55:37 it's in package aurora-daemon-0.1 Jan 22 14:57:10 what's dconf-qt? Jan 22 14:57:13 what provides it? Jan 22 14:59:46 there is a dconf package Jan 22 14:59:56 should I DEPENDS on it Jan 22 15:00:33 GNUtoo: I have a recipe here for dconf-qt Jan 22 15:00:37 will push it later Jan 22 15:00:39 ah ok Jan 22 15:00:41 I'll wait then Jan 22 15:00:51 you're building aurora-image? Jan 22 15:00:57 yes Jan 22 15:01:00 to test on crespo Jan 22 15:01:06 to see if sounds still blocks Jan 22 15:02:58 * pabs3 really hopes yr not using dconf :( Jan 22 15:04:33 pabs3: aurora will use dconf Jan 22 15:04:46 GNUtoo: what do you mean in detail with "sounds still blocks" Jan 22 15:04:47 ? Jan 22 15:05:04 let me boot crespo Jan 22 15:07:43 http://www.pastie.org/private/yhvej8hlfgfyvqxeofncnq Jan 22 15:08:02 it blocks on the last line Jan 22 15:10:01 pastie.org would be really nice, if only they wouldn't use that fsckng twilight theme per default Jan 22 15:10:54 while pastebin became unbearably overloaded with all sorts of advertisement crap in flash and whatnot Jan 22 15:11:36 indeed for pastebin.... Jan 22 15:11:40 GNUtoo: ok I only tried with aplay instead of mplayer Jan 22 15:11:46 let me try Jan 22 15:11:48 will take a look later Jan 22 15:12:06 aplay also blocks Jan 22 15:12:07 here Jan 22 15:12:42 http://www.pastie.org/private/mswnmoapvtckaj1v7dm2q Jan 22 15:12:45 hmm, maybe accepting that one cookie might fix that "problem" for me, until x-y-2013 Jan 22 15:13:55 or didn't firefox offer the possibility to choose your own css theme? Jan 22 15:14:34 GNUtoo: accepting that cookie did the trick Jan 22 15:14:39 ok Jan 22 15:15:32 for your 1. paste: ALSA tries to open pcmC0D0p Jan 22 15:15:33 GNUtoo: which lines are telling you that it is blocking? Jan 22 15:15:41 (no cookie failed to do it) Jan 22 15:16:08 [AO_ALSA] alsa-lib: pcm_hw.c:1293:(snd_pcm_hw_open) open '/dev/snd/pcmC0D0p' failed (- Jan 22 15:16:17 morphis, on aplay last line tells Jan 22 15:16:33 obviously "you" already have a plugin stack using that hw device Jan 22 15:16:36 there should be more lines like last line Jan 22 15:16:56 DocScrutinizer, yes I know that's why I killed fsodeviced Jan 22 15:17:13 you also need to kill alsa I'd guess Jan 22 15:17:57 kill alsa? Jan 22 15:17:58 also doesn't free the hw device when app pcm_close() the audio device Jan 22 15:18:09 s/also/ALSA/ Jan 22 15:18:10 DocScrutinizer meant: ALSA doesn't free the hw device when app pcm_close() the audio device Jan 22 15:18:16 afaik Jan 22 15:18:34 ok Jan 22 15:18:39 lsof might help Jan 22 15:18:56 lsof gives only aplay Jan 22 15:19:01 on pcmC0D0p Jan 22 15:19:11 the rest is control stuff Jan 22 15:19:30 hmm, so kill that aplay process? Jan 22 15:21:28 aplay was to proove that sounds blocks Jan 22 15:21:34 I killed it and retried Jan 22 15:21:36 still the same Jan 22 15:21:40 it's android stuff Jan 22 15:21:56 they put stuff in the kenrel in order not to have to write them for userland Jan 22 15:23:36 seems that card drive in >>Hardware PCM card 0 'smdkc110' device 0 subdevice 0<< is borked Jan 22 15:23:42 driver Jan 22 15:24:04 it is Jan 22 15:24:11 indeed Jan 22 15:24:17 you'd need to strace or whatever the sndkc110 driver and see why it blocks Jan 22 15:25:11 it might be an IRQ that gets lost, or some other process directly accessing the hw causing conflicts or whatever Jan 22 15:25:23 no I think it's android stuff Jan 22 15:25:24 what platform is that? Jan 22 15:25:32 crespo/herring aka nexus S Jan 22 15:25:42 hmm, nfc about that Jan 22 15:26:14 for instance at .close they reset the alsa controls in the kernel Jan 22 15:26:27 mhm, nice Jan 22 15:26:31 indeed Jan 22 15:26:33 android.... Jan 22 15:26:38 :-S Jan 22 15:27:03 ruthlessly messing up kernel, that's android Jan 22 15:27:12 indeed Jan 22 15:27:22 if you saw the things I saw...... Jan 22 15:27:39 then blame userland apps like aplay when they break on that shit Jan 22 15:27:49 ? Jan 22 15:27:56 then THEY... Jan 22 15:27:59 it's the android kernel to blame Jan 22 15:28:05 ah ok Jan 22 15:31:07 (finally the cookie still did the trick with pastie.org theme) Jan 22 15:34:26 GNUtoo: anyway on http://www.pastie.org/private/yhvej8hlfgfyvqxeofncnq mplayer tries to open direct alsa hw device aiui, that's rather bad if it's the case. mplayer should use a alsa pcm device like "default" or "dmix" or whatever aplay -L is offering. If there's no proper pcm audio devie to use, you should define one via asoundrc etc Jan 22 15:34:44 ok Jan 22 15:34:52 I didn't notice that Jan 22 15:36:34 I migth be mistaken on the diagnostic output of mplayer/alsa-lib Jan 22 15:36:57 I think it tries different things Jan 22 15:37:01 like first default Jan 22 15:37:27 anyway with -ao alsa:device=default it fails the same way Jan 22 15:39:41 the stack for aplay (your 2. pastie) also looks not very smart. (app snd_pcm_open)->pcm_route->pcm_card(smdkc110) Jan 22 15:39:52 no dmix, no pcm_plug Jan 22 15:40:03 default has dmix Jan 22 15:40:38 or should have Jan 22 15:40:41 obviously aplay doesn't use default as default then :-) Jan 22 15:40:47 ok Jan 22 15:41:06 ohhh Jan 22 15:41:13 /etc/asound.conf is not there Jan 22 15:41:21 your aplay -vvv output shows a plugin stack of route->card Jan 22 15:41:23 maybe it got removed with the removal of fsoaudiod Jan 22 15:41:28 ok Jan 22 15:41:35 so aplay opens "route" Jan 22 15:43:36 you need a proper definition of a stack for any arbitrary alsa device in e.g asoundrc (or usr/share/alsa/*/*) and then your app opens that "predefined" stack Jan 22 15:44:00 yes that's what we did Jan 22 15:44:04 I can't see how removal of fsoaudiod removes stack definitions from those alsa config files Jan 22 15:44:13 but then we introduced a regression removing fsoaudiod Jan 22 15:45:30 aplay -L is supposed to list the available stack definitions - though it recently switched to hide a lot of them, due to some "hidden" option in stack definitions Jan 22 15:45:32 morphis, we lost /etc/asound.conf during the fsoaudiod removal.... thanks a lot DocScrutinizer for making me find that Jan 22 15:46:22 morphis, with asound.conf it works again Jan 22 15:46:31 :-D Jan 22 15:46:50 I opkg installed fsoaudiod and then removed it from loading trough its config Jan 22 15:50:05 no I really like to spot the friggin "hide" directive in my alsa config here, as I hate this "new" (actually 5yo) behaviour of aplay -L Jan 22 15:50:10 now* Jan 22 16:25:17 GNUtoo: (+ to-whom-it-may-concern): search /usr/share/alsa/* for "defaults.namehint.*", set all to "on" Jan 22 16:28:44 GNUtoo: http://paste.debian.net/153192/ Jan 22 16:28:55 then do another aplay -L :-D Jan 22 16:31:56 what should I do exactly before aplay -L Jan 22 16:32:11 I add all that to alsa.conf? Jan 22 16:33:44 or just the stuff starting with the default header Jan 22 16:33:45 ? Jan 22 16:46:09 look into your /usr/share/lase/alsa.conf, find the location looking similar, edit lines like >>defaults.namehint.extended off<< to >>defaults.namehint.extended on<< Jan 22 16:47:16 or rather: grep -r namehint /usr/share/alsa/ Jan 22 16:49:35 /usr/share/alsa/alsa.conf:defaults.namehint.extended on Jan 22 16:49:53 if there's no such line like >>defaults.namehint.extended off<< and >>defaults.namehint.basic off<< and >>defaults.namehint.showall off<<, you want to add them to /usr/share/alsa/alsa.conf - of course with "on" not "off" Jan 22 16:50:08 all is on Jan 22 16:50:13 showall,basic and extended Jan 22 16:50:38 good, then aplay -L shall show you all available pcm stacks aka alsa-audio-devices Jan 22 16:51:07 wait a second Jan 22 16:51:29 that was on my desktop....doing too much thing at the same time Jan 22 16:51:48 on my desktop *now*: http://paste.debian.net/153198/ Jan 22 16:52:00 (output of aplay -L) Jan 22 16:52:15 wow Jan 22 16:52:17 ok Jan 22 16:53:27 GNUtoo: hi Jan 22 16:55:02 Alex[sp3dev], hi Jan 22 16:55:59 GNUtoo: so I added fsa9480 pdata and usb switch gpio to sgs2 kernel and usb is working now. Do i just add console=ttyACM0 now? Jan 22 16:57:04 Alex[sp3dev], hmmm Jan 22 16:57:10 can't you use ssh? Jan 22 16:57:35 I never used serial over usbnet for kernel messages Jan 22 16:57:38 GNUtoo: not really. external uSD is not working. Do you have some good initrd at hand? Jan 22 16:57:57 not with the required stuff for that kind of work Jan 22 16:58:03 GNUtoo: before and after "deafult.namehint.extended on" on maemo: http://paste.debian.net/153201/ Jan 22 16:58:43 on gta04 only basic is on Jan 22 16:58:47 showall and extended is off Jan 22 16:59:07 Alex[sp3dev], what distro do you use? Jan 22 16:59:40 GNUtoo: debian on my x86 laptop. I think I have an initrd somewhere, just need to find Jan 22 16:59:46 ok Jan 22 16:59:57 because you could generate one with openembedded Jan 22 17:00:03 but that will be quite long to compile it Jan 22 17:00:17 I wondered rather about the distro on the phone Jan 22 17:01:03 GNUtoo: I'm going to use meego. Hope st-ericsson mali blobs work. If not, we'll have to wait for FOSDEM's remali driver Jan 22 17:02:26 ok Jan 22 17:04:05 HAH, STE mali Jan 22 17:04:23 *almost*, near miss Jan 22 17:04:45 I bet I can access the sources though Jan 22 17:05:16 I think I should be able, that is... Jan 22 17:06:15 dunno if I got access to those VOBs as they probably belong to Lund, not Nuremberg Jan 22 17:06:24 mrmoku, are you sure fsodeviced segfaults? Jan 22 17:06:31 mrmoku, for me it does return 1; Jan 22 17:06:55 DocScrutinizer: that's not nice to tease the rest of us with your access to secret documentation :p Jan 22 17:07:06 haha Jan 22 17:08:24 well, I obviously mustn't disclose those sources, as I wasn't allowed to disclose datasheets of calypso, but nevertheless I might be able to help when it comes to some specific question about those blobs and how they work Jan 22 17:08:52 or s/calyso/glamo/ Jan 22 17:09:58 you might want to ping dm8tbr, he's doing sth about snowball Nova mali stuff and some hickup in licencing that STE introduced Jan 22 17:10:34 find him on e.g. #harmattan Jan 22 17:11:16 I'm on the CC of some mail traffic between him and STE Jan 22 17:11:56 GNUtoo: ah ok thats maybe the problem as fsoaudiod is still alive in aurora-image Jan 22 17:14:48 ok Jan 22 17:15:04 Alex[sp3dev]: which platform? Jan 22 17:15:09 aka board? Jan 22 17:15:18 GNUtoo: http://pastebin.com/PNpM86qJ ok, first dmesg Jan 22 17:15:32 DocScrutinizer: galaxy s2/exynos4210 Jan 22 17:15:55 aaaah samsung galaxy, yeah I knew samsung using STE chipset Jan 22 17:16:07 no they are not Jan 22 17:16:26 sure they do :-) Jan 22 17:16:44 they're using their own SoC. It's just that the only mali userland driver i've found was for ste Jan 22 17:16:47 maybe not in this galaxy, but then... what's that talk about mali all about? Jan 22 17:17:10 aah Jan 22 17:20:42 Alex[sp3dev], how did you get that console=ttySAC0? Jan 22 17:21:21 hmm OK, http://pdadb.net/index.php?m=pdamaster http://pdadb.net/index.php?m=cpu&id=a9500&c=st-ericsson_nova_a9500 Jan 22 17:22:02 GNUtoo: no, I have found an initrd with telnet on my laptop Jan 22 17:22:20 ah ok Jan 22 17:23:31 http://www.google.de/search?q=ericsson+nova also NovaThor (/me "is" Thor :-D) Jan 22 17:24:49 I.E while A9500 is terra incognita to me - job wise - the U9500 is my daily task Jan 22 17:29:07 mrmoku: ping Jan 22 17:29:37 mrmoku: http://http://build.shr-project.org/ Jan 22 17:29:46 mrmoku: Downloads -> some image type -> some device -> tar.gz Jan 22 17:29:53 mrmoku: something like that? Jan 22 17:34:16 pespin, hi Jan 22 17:34:26 GNUtoo, hi :) Jan 22 17:34:45 pespin, is it possible to autostart bluetoothd trough bluetooth? Jan 22 17:34:56 or does fsodeviced need to spawn it trough system Jan 22 17:35:20 hmm it could be autostarted by dbus I guess Jan 22 17:35:38 # mdbus2 -s org.bluez Jan 22 17:35:38 Segmentation fault Jan 22 17:35:40 hmmm Jan 22 17:35:43 o.O Jan 22 17:35:47 lol Jan 22 17:36:07 that's the effect of autostart Jan 22 17:36:23 I haven't have that problem Jan 22 17:36:54 GNUtoo, but afaik it could be better to jut launch it when the hw becomes powered Jan 22 17:37:24 ie. if I turn on bluetooth, then bluetoothd should automatically connect the audio to my headsets without having to call anything Jan 22 17:37:30 I just tought about replacing the system-like launch by a dbus launch Jan 22 17:37:56 pespin, that may be the case already, I need to check Jan 22 17:38:01 I think it is sometimes launched by udev, could that be posible? Jan 22 17:38:21 but we don't have udev right? Jan 22 17:38:43 indeed Jan 22 17:38:45 no udev Jan 22 17:38:50 then fso should launch it if it's not launched when we power on bluetooth resource Jan 22 17:39:03 that's why you asked me to make fso launch it in the past Jan 22 17:39:08 yeah Jan 22 17:39:10 and it worked Jan 22 17:39:15 until now on gta04 Jan 22 17:39:40 it is working here in gta02 i think Jan 22 17:39:56 ok Jan 22 17:40:09 on gta04 the rfkill plugin is broken Jan 22 17:40:12 can you gdb mdbus2? Jan 22 17:40:13 I'm currently looking why Jan 22 17:40:16 yes Jan 22 17:40:22 it should not segfault Jan 22 17:41:06 http://www.stericsson.com/products/m570-thor.jsp <- /me; http://www.stericsson.com/products/m7400-thor.jsp *&&~/me Jan 22 17:41:43 http://www.pastie.org/3231980 Jan 22 17:45:48 heh nice, my valac generates different C output Jan 22 17:48:02 SHR: 03morphis 07meta-smartphone * rb7bd4932a7b7 10/meta-aurora/recipes-aurora/aurora/aurora-base.inc: meta-aurora: aurora-base: bump SRCREV Jan 22 17:48:03 SHR: 03morphis 07meta-smartphone * r27301723bc78 10/meta-fso/recipes-freesmartphone/freesmartphone/fsoaudiod_git.bb: meta-fso: fsoaudiod: get in sync again with cornucopia Jan 22 17:48:03 SHR: 03morphis 07meta-smartphone * r00edfe66a032 10/meta-aurora/recipes-qt/dconf-qt/dconf-qt_git.bb: meta-aurora: dconf-qt: add first version of the recipe Jan 22 17:48:13 SHR: 03morphis 07meta-smartphone * r8be0d6553af1 10/meta-fso/recipes-freesmartphone/freesmartphone/cornucopia.inc: meta-fso: cornucopia: bump SRCREV Jan 22 17:48:14 SHR: 03morphis 07meta-smartphone * r1a756a221e03 10/meta-fso/recipes-freesmartphone/freesmartphone/libsamsung-ipc_git.bb: meta-fso: libsamsung-ipc: bump SRCREV Jan 22 17:48:58 ah no, I had an older mdbus2 version, now I get the error too Jan 22 17:53:53 bbl Jan 22 17:56:42 GNUtoo: istn't this a potential problem?: warning: the debug information found in "/lib/.debug/libgcc_s.so.1" does not match "/lib/libgcc_s.so.1" (CRC mismatch). Jan 22 17:57:19 mrmoku: warning is now displayed also in file listing for */images/* directories Jan 22 17:59:23 GNUtoo, in main.vala line 229 -> foreach ( var node in nodeinfo.nodes ) and in this case nodeinfo is null, that's the cause of the segfault Jan 22 18:06:17 GNUtoo, the patch consists on adding a line like this before the foreach line -> if(nodeinfo==null) throw new GLib.ERROR_WHATEVER("this service is not available!"); Jan 22 18:07:05 but I have to leave now, I'll send patch tomorrow if you don't feel like doing it :) Jan 22 18:07:29 quick fix if(nodeinfo==null) return; should work too hehe Jan 22 18:07:53 GNUtoo, anyway, enabling debug at compile time shows this before segfault -> ** (mdbus2:12773): DEBUG: main.vala:645: Cannot introspect org.bluez /: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez was not provided by any .service files Jan 22 18:11:01 and that should already keep the app from executing the code that segfaults Jan 22 18:11:53 seems somebody been a tiny bit lazy when coding it, as there's obviously some (a lot of?) error checking and handling missing Jan 22 18:12:46 according to general rule that says you shall have a error handler for each line that could fail in whatever way Jan 22 18:13:29 or simply put: returncodes never are type void Jan 22 18:17:12 if it helps your coding style, you may imagine you get shot whenever your code segfaults Jan 22 18:19:13 I think none of my code ever segfaulted after initial development and debug phase where occasionally a one-off array pointer caused some problems Jan 22 18:20:24 DocScrutinizer: btw python adds a new dimension: you never know if some line can fail or not because exceptions are possible everywhere :) Jan 22 18:21:35 rather I got error msgs like e.g. "OUCH, somebody messed up my linked list! NextPtr invalid: 0xffff34a2 line: 577 in foobar" Jan 22 18:22:40 PaulFertser: \o/ Jan 22 18:24:10 indeed you sometimes see a segfault when correctly using some lib functions that are borked - little you can do about that then Jan 22 18:25:45 DocScrutinizer: dynamic languages are "inherently different". That's why they like test-driver-development (i.e. writing testcases for all possible codepathes in advance) :) Jan 22 18:26:01 anyway I'm a freak - I'm probably the only one on God's great earth that checks return codes of close() Jan 22 18:26:49 PaulFertser: that's also why I hate dynamic languages Jan 22 18:27:54 and, believe it or not, I've already seen close() fail Jan 22 18:28:20 again, usually little you can do Jan 22 18:28:37 except maybe retry later Jan 22 18:29:19 snd_pcm_close() loves to fail ;-D Jan 22 18:30:15 if you forget to snd_pcm_free_hwdevice() before (or whatever was the name of that call) Jan 22 18:32:18 michel deboer rejected my suggestion to check return code though, and claimed that now that it's fixed the close() shouldn't be able to fail anymore Jan 22 18:32:41 in twinkle audiodev Jan 22 18:33:37 so I'm still the only weirdo on earth that does return code check of close() in his code ;-D Jan 22 18:34:33 pespin|away, that's because I used dbus to launch it Jan 22 18:35:28 man 2 close : >> RETURN VALUE close() returns zero on success. On error, -1 is returned, and errno is set appropriately. << Jan 22 18:38:22 :-D :-P >> NOTES Not checking the return value of close() is a common but nevertheless serious programming error. It is quite pos- sible that errors on a previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and with disk quota. << Jan 22 18:40:18 DocScrutinizer: what has to be done if the close does fail ? Jan 22 18:40:26 close again ? Jan 22 18:41:15 good question. Depends, but usually there's little you can do except either err out gracefully, or rollback and redo the whole transaction Jan 22 18:41:54 e.g you might want to eraste and create new that file you just written Jan 22 18:42:25 DocScrutinizer: this is a serious question because its the same problem of silenty catch exceptions Jan 22 18:42:34 of course you need an error counter then as well, to fail gracefully after 3 retries Jan 22 18:42:36 GNUtoo: not sure it segfaults... might as well just returned Jan 22 18:42:41 I just noticed it was not started anymore Jan 22 18:42:45 dos1: what do you mean? Jan 22 18:43:12 dos1: ahh, now I see... very VERY good :-D Jan 22 18:44:03 dos1: that will let our support team take a break of repeating it again and again ;) Jan 22 18:44:40 mrmoku, it doesn't segfault indeed Jan 22 18:45:49 :) Jan 22 18:46:08 mrmoku: i'll also add downloading bootloader and kernel to download wizard, but later Jan 22 18:47:12 good Jan 22 18:47:26 GNUtoo: do you know already where it does return? Jan 22 18:48:54 mrmoku, not yet Jan 22 18:49:11 I think it's related to dbus Jan 22 18:49:13 look at that: Jan 22 18:49:26 2012-01-21T22:11:31.008912Z [CRITICAL] subsystem : Can't claim busname org.freesmartphone.odeviced Jan 22 18:49:35 that's with the rfkill plugin Jan 22 18:50:00 nschle85: on complex programs in a industrial productive environment, I usually determine what's a "transaction" in that context, and I trigger rollback of the transaction (this can involve moving foo.backap back to foo, as well as dealing with all internal states of the program), then I set "rollback-done-now-redo" flag and repeat the transaction from beginning. If *any* error occurs while that flag is set, the program only does Jan 22 18:50:02 emergency rollback without any error checking and then throws error and dumps diagnostic Jan 22 18:50:04 without it it sits easily on the bus Jan 22 18:52:15 DocScrutinizer: i understand, but what has to be done in the concrete situation ? is the return code correct ? Jan 22 18:52:34 which concrete situation? Jan 22 18:53:08 snd_pcm_close() loves to fail ;-D Jan 22 18:53:14 aaah Jan 22 18:53:51 well, there's little you can do, just fix your program to have snd_psm_free() before snd_pcm_close() Jan 22 18:54:27 depending on return code (-EAGAIN?) you might consider to redo the snd_pcm_free() Jan 22 18:55:12 when snd_pcm_close() fails you just can rise a "WARNING: audio hw in a pathologic state. Dunno how to recover - aborting" Jan 22 18:55:40 so why close does not try to free ? Jan 22 18:55:50 mrmoku, it's in handle event Jan 22 18:55:56 or rather "WARNING: audio hw in a pathologic state. Dunno how to recover - expect program failure on next open()" Jan 22 18:57:51 mrmoku, commenting that line fixes it: Jan 22 18:57:52 handleEvent( event ); Jan 22 19:03:28 mrmoku, now comenting that line makes it work: Jan 22 19:03:30 / instances.insert( (int)event.idx, new Kernel26.RfKillPowerControl( event.idx, event.type, event.soft == 1, event.hard == 1 ) ); Jan 22 19:04:29 in C it's: Jan 22 19:04:30 g_hash_table_insert (_tmp18_, GINT_TO_POINTER ((gint) _tmp20_), _tmp29_); Jan 22 19:04:58 nschle85: luckily we have a ALSA doc that is extremely vebose about all that ;-) http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#gff39173ece95bba5fa69bc6ea15634e6 Jan 22 19:05:26 mrmoku, http://www.pastie.org/3232354 Jan 22 19:05:54 DocScrutinizer: Closes the specified PCM handle and frees all associated resources. Examples: Jan 22 19:06:11 so close works without free ? Jan 22 19:06:14 http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#gd9d9a6795127aaf349ccc728d7687fc0 Jan 22 19:06:42 obviously not, as we had to learn by painful example in project twinklephone Jan 22 19:06:46 ah no Jan 22 19:06:58 the "new" things makes it not work Jan 22 19:07:04 must have been old C source then Jan 22 19:07:41 nschle85: at least not always Jan 22 19:08:32 DocScrutinizer: so the documentation is wrong Jan 22 19:08:42 or the code ? Jan 22 19:09:13 http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2latency_8c-example.html#a55 Jan 22 19:09:30 whatever, the example uses snd_psm_hw_free() Jan 22 19:12:12 DocScrutinizer: and what do you think ? which behavior is the best ? close does also free or free and close are separate actions Jan 22 19:12:26 ? Jan 22 19:12:39 err Jan 22 19:12:53 I'd simply always do a free before close Jan 22 19:13:24 GNUtoo: looking it the c code it's quite clear that it aborts Jan 22 19:13:35 ok that pragmatic but understandable Jan 22 19:14:17 GNUtoo: it is using _tmp18_ as hashtable without actually creating it Jan 22 19:14:55 nschle85: if you really want to understand all that, you probably have to read the ALSA source Jan 22 19:15:26 as I always failed to find any decent spec that elaborates on such aspects of ALSA Jan 22 19:15:53 GNUtoo: and looking at the vala code I know what is happening (I think) Jan 22 19:15:53 mrmoku, can you fix it? Jan 22 19:16:26 GNUtoo: when fsodeviced starts up rfkill is not yet there Jan 22 19:16:29 (is my theory) Jan 22 19:16:32 ok Jan 22 19:16:50 then I'll let you fix it because I don't understand the code well Jan 22 19:16:51 DocScrutinizer: hmm i think reading the api doc should be enough :-) but i know about that problem, at the moment i have the problem migrating to java7 (from 6 ) the documentation did not change but the implementation is not compatible at all Jan 22 19:17:03 this rfkill code is one of the code I don't understand .... Jan 22 19:17:16 nothing really to do with rfkill though Jan 22 19:17:33 yes but the whole plugin is written in such a way that I didn't understand before Jan 22 19:17:37 fsodeviced checks for /dev/rfkill in the factory function of that plugin Jan 22 19:17:41 not sure if I understand it or not reading it again Jan 22 19:17:42 if it is not there Jan 22 19:17:48 it won't create the hashtable Jan 22 19:17:50 let me look Jan 22 19:18:04 you should have this in the logs: Jan 22 19:18:05 FsoFramework.theLogger.error( @"Can't open $devfs_root/rfkill: $(strerror(errno)); rfkill plugin will not be operating" ); Jan 22 19:18:06 crw------- 1 root root 10, 63 Jan 1 1970 /dev/rfkill Jan 22 19:18:06 nschle85: should or ought? I never found an API spec that would explain what for you need and use snd_pcm_hw_free() Jan 22 19:18:49 mrmoku, I don't Jan 22 19:18:49 nschle85: if you got a link to such spec, I'd really like you to share it Jan 22 19:18:55 GNUtoo: yeah, but the rfkill module might have been loaded *after* start of fsodeviced Jan 22 19:18:58 hmm... Jan 22 19:19:01 ok Jan 22 19:19:06 then my theory obviously is wrong :/ Jan 22 19:19:15 indeed lol Jan 22 19:19:23 but the thing I'm sure : Jan 22 19:19:40 instances.insert( (int)event.idx, new Kernel26.RfKillPowerControl( event.idx, event.type, event.soft == 1, event.hard == 1 ) ); Jan 22 19:19:48 commenting this line makes it load etc... Jan 22 19:19:50 guess then it's something for one of the vala experts Jan 22 19:19:58 and something else that broke with bumping vala Jan 22 19:20:02 could you look? Jan 22 19:20:06 internal HashTable instances; Jan 22 19:20:10 because I'm by no mean a vala expert Jan 22 19:20:16 * mrmoku neither Jan 22 19:20:25 yes but you know vala better than me Jan 22 19:20:37 morphis: ping Jan 22 19:20:59 so you would be better armed to discuss with the vala experts Jan 22 19:21:52 I can't take care tonight though Jan 22 19:21:58 GNUtoo: hello , how are u man fine ? this is respond of stefan schimdt > The number of shown partitions is hardcoded atm to DFU_NUM_ALTERNATES Jan 22 19:21:58 which is set to 6. So you last partition does not get shown increment Jan 22 19:21:58 it to seven in your board config and re-compile your u-boot and test Jan 22 19:21:58 again. Jan 22 19:22:25 mrmoku: hi man Jan 22 19:22:35 hi alabd Jan 22 19:22:47 and sorry... because I'm off now ;) Jan 22 19:23:04 ah ok ouch Jan 22 19:23:16 so I guess I msust investigate more? Jan 22 19:23:20 nop that was sending hi mrmoku good night Jan 22 19:23:22 what can I do? Jan 22 19:23:29 and what should I do once the plugin works Jan 22 19:23:41 because I need rfkill + ifconfig Jan 22 19:26:38 GNUtoo: would you change 6 to 7 and recompile it because don't have board myself here Jan 22 19:51:06 mrmoku: shr-2012.01? Jan 22 19:51:15 is this some kind of shr-stable? :o Jan 22 19:51:48 should i update download wizard to include it? Jan 22 20:27:25 SHR: 03GNUtoo 07meta-smartphone * r7a1240f6466c 10/meta-aurora/recipes-aurora/aurora/aurora-daemon_git.bb: meta-aurora: aurora-daemon: fix configure dependencies Jan 22 20:27:35 SHR: 03GNUtoo 07meta-smartphone * rf458537fb798 10/meta-aurora/recipes-aurora/aurora/aurora-daemon_git.bb: meta-aurora: aurora-daemon: fix LIC_FILES_CHKSUM Jan 22 20:31:08 btw for your alsa forearder pcmspeech thingie this source should hold some interesting details Jan 22 20:31:12 http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2latency_8c-example.html Jan 22 20:31:57 like for example >>Scheduler is set to SCHED_RR. Jan 22 20:33:47 basically I think you could use it to forward from cmt_speech alsa device "ADC" to earpiece alsa device DAC, and from mic ADC to cmt_speech "DAC" without any modifications Jan 22 20:34:29 mrmoku: GNUtoo ^^^ Jan 22 20:37:19 indeed Jan 22 20:37:27 antrik, was looking for that too Jan 22 20:39:52 hey GNUtoo, I was sent here from #angstrom. im trying to hunt down information on setting up some (any) linux on my old Tungsten|E. do you have any pointers as to where i could find either a fresher/functional image or where i should look to build my own? ive got a few old images, but they're mostly ancient/broken :/ . Thanks Jan 22 20:40:22 hawk-i, hi , does this device has telephony? Jan 22 20:40:44 i dont believe so. it's pretty much just a usb port and an sd card reader Jan 22 20:40:52 i havent a modem or anything for it Jan 22 20:40:55 it's a Palm Jan 22 20:41:21 http://en.wikipedia.org/wiki/Palm_Tungsten#Tungsten_E Jan 22 20:41:40 hmmm Jan 22 20:42:01 the problem is that we aim at smartphone, angstrom is better suited for general purpose computers like PDA Jan 22 20:42:11 but if you want to add support for it we can help you Jan 22 20:42:44 GNUtoo: i guided hawk-i: here because you know alot of devices and you may know that Tungsten is supported by oe or not Jan 22 20:43:22 ah supported by oe Jan 22 20:43:28 ya, the device is listed on OE it seems, im just not entirely sure if it is actually supported... most projects like Garux have all but dried up Jan 22 20:43:35 ok Jan 22 20:43:46 the thing is that you must look if it's supported by oe-core Jan 22 20:43:53 look in theses layers: Jan 22 20:44:00 http://www.openembedded.org/wiki/LayerIndex Jan 22 20:44:05 but let's talk in #oe Jan 22 20:44:06 GNUtoo: in my oppinion angstom channel is dead so let him die there would be unpolite :-) Jan 22 20:44:14 GNUtoo: Jan 22 20:44:17 00453 "Tip #1 (usable latency with large periods, non-blocking mode, good CPU usage,\n" Jan 22 20:44:19 00454 " superb xrun prevention):\n" Jan 22 20:44:20 00455 " latency -m 8192 -M 8192 -t 1 -p\n" Jan 22 20:44:22 00456 "Tip #2 (superb latency, non-blocking mode, but heavy CPU usage):\n" Jan 22 20:44:23 00457 " latency -m 128 -M 128\n" Jan 22 20:44:51 awesome GNUtoo, this is a good start. ill meet you over at #oe Jan 22 20:44:56 DocScrutinizer, what are theses arguments, do they come from alsaloop? Jan 22 20:45:23 these are arguments to latency binary, as shown in latency's help Jan 22 20:45:30 hawk-i: nice idea, hope i could help Jan 22 20:46:11 http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2latency_8c-example.html Jan 22 20:46:40 ok Jan 22 20:47:04 ah latency in frames Jan 22 20:50:43 * DocScrutinizer idly wonders if latency is available for installation as a precompiled binary somewhere Jan 22 20:50:52 for x86 / suse Jan 22 20:51:01 I think it is Jan 22 20:51:08 I wonder where Jan 22 20:51:20 alsa-utils-latency maybe Jan 22 20:51:29 I'll look as soon as I finish my long wiki edition Jan 22 20:51:47 no such thing like alsa-utils-latenc alsa-utils and alsa-tools seem to not contain it Jan 22 20:52:41 :-/ Jan 22 20:52:53 zypper search latency also doesn't help Jan 22 20:56:00 hmmm Jan 22 20:56:07 then gcc alsa-utils.c -l etc... Jan 22 20:57:15 thought as much Jan 22 20:57:29 will get nasty with all the alsa-dev libs Jan 22 21:07:34 GNUtoo: http://elinux.org/images/8/82/Elc2011_lorriaux.pdf Jan 22 21:16:09 ok thanks a lot Jan 22 21:16:45 DocScrutinizer, I did a bit of real time audio long time ago with jack + ardour Jan 22 21:16:57 at user level only tough Jan 22 21:18:09 I didn't realize that latency not only measures latency but also seems to automatically find optimal settings Jan 22 21:18:21 ah ok wow Jan 22 21:18:37 and my repeated remark about scheduling got confirmed Jan 22 21:18:53 what remark? Jan 22 21:18:58 about clocks? Jan 22 21:19:10 or about scheduling realtime the app Jan 22 21:19:12 you want realtime aka RR scheduling for your forwarder process Jan 22 21:19:20 ok Jan 22 21:19:42 it's very important so I'll try not to forget Jan 22 21:19:56 obviously a CPU load of <1% should be feasible Jan 22 21:20:08 it's already working pretty well Jan 22 21:20:16 bye Jan 22 22:19:54 Project shr-core-setup build #3: SUCCESS in 15 sec: http://norman-schleicher.de/jenkins/job/shr-core-setup/3/ Jan 22 22:36:46 SHR: 03Martin.Jansa 07shr-chroot * r627a521ff434 10/ (1614 files in 56 dirs): system upgrade Jan 22 23:08:39 Project shr-core-om-gta02-shr-image build #71: SUCCESS in 48 min: http://norman-schleicher.de/jenkins/job/shr-core-om-gta02-shr-image/71/ Jan 22 23:11:52 Project shr-core-om-gta02-feed build #10: SUCCESS in 3 min 12 sec: http://norman-schleicher.de/jenkins/job/shr-core-om-gta02-feed/10/ Jan 22 23:14:01 Project shr-core-om-gta02-aurora-image build #12: FAILURE in 2 min 8 sec: http://norman-schleicher.de/jenkins/job/shr-core-om-gta02-aurora-image/12/ Jan 22 23:36:48 SHR: 03shr-devel 07buildhistory * re11f194d3d8b 10/packages/ (187 files in 187 dirs): Build 201201222323 of shr 20120122 for machine om-gta02 on shr-chroot Jan 23 00:14:14 Project shr-core-nokia900-shr-image build #55: SUCCESS in 1 hr 0 min: http://norman-schleicher.de/jenkins/job/shr-core-nokia900-shr-image/55/ Jan 23 00:27:49 Project shr-core-nokia900-feed build #9: SUCCESS in 13 min: http://norman-schleicher.de/jenkins/job/shr-core-nokia900-feed/9/ Jan 23 00:30:12 Project shr-core-nokia900-aurora-image build #12: FAILURE in 2 min 23 sec: http://norman-schleicher.de/jenkins/job/shr-core-nokia900-aurora-image/12/ Jan 23 00:53:28 SHR: 03shr-devel 07buildhistory * r2d74b3564ea2 10/packages/ (187 files in 187 dirs): Build 201201230037 of shr 20120122 for machine nokia900 on shr-chroot Jan 23 01:27:43 SHR: 03shr-devel 07buildhistory * rbf5e18ced889 10/packages/palmpre-oe-linux-gnueabi/ (50 files in 50 dirs): Build 201201230154 of shr 20120123 for machine palmpre on shr-chroot Jan 23 02:02:34 SHR: 03shr-devel 07buildhistory * r9910c67df6de 10/packages/palmpre2-oe-linux-gnueabi/ (50 files in 50 dirs): Build 201201230228 of shr 20120123 for machine palmpre2 on shr-chroot Jan 23 02:35:47 SHR: 03shr-devel 07buildhistory * rffd2a9663a74 10/packages/crespo-oe-linux-gnueabi/ (50 files in 50 dirs): Build 201201230302 of shr 20120123 for machine crespo on shr-chroot **** ENDING LOGGING AT Mon Jan 23 02:59:57 2012