**** BEGIN LOGGING AT Wed Dec 07 02:59:57 2011
Dec 07 03:44:27 * pabs3 wonders whats the license of that Miso.ttf
Dec 07 06:36:03 <mrmoku> moin
Dec 07 07:48:18 <JaMa> moin
Dec 07 09:06:05 <CIA-82> SHR: 03Martin.Jansa 07shr-chroot * r286c19b84a52 10/ (5233 files in 326 dirs): system upgrade
Dec 07 09:11:51 <morphis> heyho
Dec 07 09:11:59 <morphis> mickeyl: ping
Dec 07 09:12:01 <CIA-82> SHR: 03Martin.Jansa 07shr-chroot * r9c39ed37ceb0 10/OE/ (13 files): sync scripts and bashrc from 64bit
Dec 07 09:13:09 <JaMa> heyho
Dec 07 09:29:17 <mrmoku> JaMa: I installed latest, closed staging and will use it as daily now
Dec 07 09:29:33 <mrmoku> so far it looks good
Dec 07 09:29:57 <mrmoku> apart from the keyboard not popping up automatically anymore
Dec 07 09:30:14 <mrmoku> dunno if that changed in elementary and has to be requested explicitely now
Dec 07 09:30:31 <mrmoku> that is kind of bad for the first start wizard... you can't pop it up manually there :P
Dec 07 09:33:34 <JaMa> n900 or gta?
Dec 07 09:34:00 <mrmoku> gta02
Dec 07 09:34:52 <mrmoku> I installed 003 on n900 too
Dec 07 09:34:58 <mrmoku> did not boot on first try though
Dec 07 09:35:02 <mrmoku> have to look into it
Dec 07 09:35:09 <mrmoku> probably just the SD not mounted correctly
Dec 07 09:35:18 <JaMa> ok, I have fsodeviced log from n900 (with almost zero brigtness bug) but I have to transfer them somewhere where it's faster to read them :)
Dec 07 09:36:40 <mrmoku> indeed SD was not in properly
Dec 07 09:36:43 <mrmoku> now it boots
Dec 07 09:51:29 <mrmoku> and has the backlight issue
Dec 07 09:53:20 <pespin> JaMa, hi! I pushed your emtooth2 stuff, rev 164
Dec 07 09:54:39 <mrmoku> JaMa: no usb network either... that makes it difficult :)
Dec 07 09:57:06 <mrmoku> bbl
Dec 07 10:21:10 <JaMa> mrmoku: I had to switch from g_nokia to g_ether to get usb networking working..
Dec 07 10:29:41 <CIA-82> SHR: 03Martin.Jansa 07shr-chroot * re6c447750dac 10/var/ (7 files in 3 dirs): bitbake upgrade
Dec 07 10:32:05 <CIA-82> SHR: 03Martin.Jansa 07shr-chroot * r3a71034f33cc 10/ (36 files in 12 dirs): bitbake upgrade
Dec 07 10:32:58 <dos1> http://build.shr-project.org/tests/site/
Dec 07 10:33:29 <dos1> i think only shr-core-staging support is left (selecting other image than latest)
Dec 07 10:34:13 <JaMa> dos1: latest shr-core-staging not always have images
Dec 07 10:34:24 <morphis> dos1: the site looks really great!
Dec 07 10:34:50 <dos1> JaMa: yup, so i have to suport that somehow
Dec 07 10:35:17 <dos1> morphis: :)
Dec 07 10:35:30 <morphis> HTML5 is a great thing :)
Dec 07 10:38:43 <morphis> JaMa: btw. we should add the image + kernel filename to the list add http://shr-project.org/trac/wiki/StagingTests
Dec 07 10:38:56 <morphis> JaMa: as the Aurora, SHR Full, SHR Lite can be used
Dec 07 10:39:00 <morphis> + the different kernels
Dec 07 10:40:55 <JaMa> we can consider Lite and Full the same functionality wise imho.. but I'll add shr/aurora as special type for 004
Dec 07 10:42:40 <GarthPS> hi huys. nice work ! :) 
Dec 07 10:44:20 <GarthPS> can someone has an hint for me ? I want to build vlc and it faild because of mising libmad but libmab can't be build because of this :
Dec 07 10:44:22 <GarthPS> ERROR: libmad was skipped: because it may require a commercial license to ship in a product (listed in COMMERCIAL_LICENSE)
Dec 07 10:44:35 <GarthPS> where do I set COMMERCIAL_LICENSE and to what ?
Dec 07 10:45:53 <JaMa> to empty in local.conf
Dec 07 10:46:10 <JaMa> there is an example i belive in latest local.conf from SHR
Dec 07 10:47:02 <JaMa> GarthPS: http://git.shr-project.org/git/?p=shr-makefile.git;a=blobdiff;f=conf/shr-core/local.conf;h=05ad42277644bbb0e4091f1b663333e732e2bcf0;hp=dd1bf9d6b22ab42a1a6d9712d9f61eda031d24a8;hb=add788602ec621598fc4b17fd778a44f1ec0beec;hpb=24c4ca22169abeee6cb5d509bfb7ecc3a38eeb55
Dec 07 10:47:19 <morphis> JaMa: ok
Dec 07 10:52:17 <morphis> JaMa: and how do you build the several testing images?
Dec 07 10:53:54 <JaMa> the process is still the same only rsync after build is different
Dec 07 10:54:46 <JaMa> alias bbaif="bb -k shr-lite-image shr-image aurora-image | tee -a log.\${MACHINE}; bb -k task-shr-feed | tee -a log.\${MACHINE}; reindex"
Dec 07 10:54:55 <CIA-82> SHR: 03morphis 07meta-smartphone * r0c9d603426d3 10/meta-samsung/recipes-kernel/linux/ (linux-samsung-crespo/defconfig linux-samsung-crespo_git.bb): meta-samsung: linux-samsung-crespo: update defconfig to support ALSA dmix plugin and bump PR
Dec 07 10:54:59 <CIA-82> SHR: 03morphis 07meta-smartphone * r0418bb9eff98 10/meta-aurora/recipes-aurora/aurora/aurora-base.inc: meta-aurora: aurora-base: bump SRCREV
Dec 07 10:55:09 <CIA-82> SHR: 03morphis 07meta-smartphone * r32d01f094598 10/meta-aurora/recipes-aurora/aurora/aurora-base.inc: meta-aurora: aurora-base: bump SRCREV to fix compilation error with libx11
Dec 07 10:55:09 <JaMa> and for cycle to call it for each machine
Dec 07 10:55:15 <morphis> JaMa: ok
Dec 07 11:12:48 <GNUtoo> I think I have the fix for mplayer
Dec 07 11:13:12 <GNUtoo> I'll push it
Dec 07 11:14:25 <morphis> GNUtoo: heyho
Dec 07 11:14:30 <morphis> GNUtoo: I have ALSA with dmix working
Dec 07 11:14:39 <morphis> with the android kernel
Dec 07 11:14:44 <morphis> and without broonie modifications
Dec 07 11:15:01 <morphis> s/broonie/broonie's/
Dec 07 11:15:02 <apt> morphis meant: and without broonie's modifications
Dec 07 11:15:42 <GNUtoo> morphis, ok nice
Dec 07 11:15:55 <morphis> GNUtoo: you just need to disable CONFIG_S5P_INTERNAL_DMA
Dec 07 11:16:03 <GNUtoo> ah ok
Dec 07 11:16:18 <GNUtoo> what about the controls ?
Dec 07 11:16:20 <morphis> I played a little bit with it playing multiple audio files at the same time
Dec 07 11:16:33 <morphis> we can use the Android set of controls
Dec 07 11:16:37 <GNUtoo> ok
Dec 07 11:16:39 <morphis> would be easier
Dec 07 11:16:49 <morphis> otherwise I got it working with broonie's kernel too
Dec 07 11:16:56 <GNUtoo> android set of controls are somehow buggy
Dec 07 11:17:02 <morphis> really?
Dec 07 11:17:14 <GNUtoo> yes I know why there is bad sound sometimes
Dec 07 11:17:24 <GNUtoo> I suspect that some routing paths are forbidden
Dec 07 11:17:40 <GNUtoo> in the sense that if you go there it put the CODEC in a bad state
Dec 07 11:17:47 <GNUtoo> and after you need to reboot
Dec 07 11:18:04 <GNUtoo> I've mplayer2 working on om-gta02 btw
Dec 07 11:18:09 <morphis> great
Dec 07 11:18:25 <morphis> so what do you think, should we use android controls or the real ones from broonie's kernel?
Dec 07 11:18:36 <GNUtoo> hmmm
Dec 07 11:18:41 <GNUtoo> the android ones may be buggy
Dec 07 11:18:47 <morphis> I don't have any clue how to figure out which controls we need to set for getting call audio working
Dec 07 11:18:48 <GNUtoo> the bronie ones may break your device
Dec 07 11:18:52 <morphis> yes
Dec 07 11:19:01 <morphis> so I think we should stay with android ones
Dec 07 11:19:05 <GNUtoo> ok
Dec 07 11:19:09 <morphis> but we need to fix the alsamixer-thing
Dec 07 11:19:15 <GNUtoo> yes 
Dec 07 11:19:27 <morphis> so we don't need to set the controls to their correct values everytime someone wants to play audio
Dec 07 11:19:27 <GNUtoo> but maybe that can be worked arround
Dec 07 11:19:30 <GNUtoo> with amixer
Dec 07 11:19:37 <morphis> how?
Dec 07 11:19:47 <GNUtoo> simply by setting the value directly
Dec 07 11:20:06 <GNUtoo> and not by cycling trough the values
Dec 07 11:20:07 <GNUtoo> however
Dec 07 11:20:27 <GNUtoo> it doesn't fix the fact that it removes the settings at .close
Dec 07 11:21:11 <morphis> yes
Dec 07 11:21:24 <morphis> and for this we need to find a work-around
Dec 07 11:22:04 <GNUtoo> no
Dec 07 11:22:09 <GNUtoo> we need to fix it in the code
Dec 07 11:22:24 <GNUtoo> it would be easier
Dec 07 11:23:26 <morphis> ok, do you know where?
Dec 07 11:23:42 <morphis> btw. whats the state for wifi?
Dec 07 11:24:18 <morphis> and about your not-working telephony on crespo device: it works fine here with ${AUTOREV}
Dec 07 11:24:47 <JaMa> GNUtoo: please be more carefull with extra newlines on wiki, ie: http://www.shr-project.org/trac/wiki/StagingTests?action=diff&version=19
Dec 07 11:25:04 <morphis> and I am currently taking a look at your code for setting up the GPRS conneciton with android 
Dec 07 11:25:08 <GNUtoo> morphis, ok
Dec 07 11:25:49 <GNUtoo> JaMa, ok btw music fails and I've a fix
Dec 07 11:26:09 <JaMa> good
Dec 07 11:26:41 <GNUtoo> the fix is a better mplayer.conf
Dec 07 11:26:48 <GNUtoo> with alsa and tremor instead
Dec 07 11:26:52 <GNUtoo> but only for om-gta02
Dec 07 11:27:19 <morphis> GNUtoo: do you have some log output for me about the PDP part in the ril?
Dec 07 11:27:32 <GNUtoo> morphis, yes let me look
Dec 07 11:28:26 <morphis> and you need to listen for IPC_GPRS_IP_CONFIGURATION unsolicited response message
Dec 07 11:29:42 <GNUtoo> ok
Dec 07 11:29:48 <GNUtoo> I did that instead:
Dec 07 11:29:55 <GNUtoo> netcfg dhcp rmnet0
Dec 07 11:29:58 <GNUtoo> or something like that
Dec 07 11:30:04 <morphis> no
Dec 07 11:30:07 <morphis> that doesn't work
Dec 07 11:30:15 <GNUtoo> ahhh ok
Dec 07 11:30:17 <morphis> you need to use the IP settings which comes with the response
Dec 07 11:30:21 <GNUtoo> ok
Dec 07 11:30:35 <GNUtoo> it worked on qualcomm devices tough
Dec 07 11:30:38 <GNUtoo> that's why I did it
Dec 07 11:30:41 <morphis> hm
Dec 07 11:30:47 <morphis> for me it didn't worked
Dec 07 11:32:00 <GNUtoo> ok
Dec 07 11:34:22 <GarthPS> JaMa: thx! 
Dec 07 11:34:32 <JaMa> GarthPS: ?
Dec 07 11:34:32 * GarthPS don't know what is commercial licence..
Dec 07 11:34:36 <JaMa> ah
Dec 07 11:35:42 <GarthPS> JaMa: and byt the way  what is this for ? "export BBFETCH2=True"
Dec 07 11:35:54 <GNUtoo> morphis, http://www.pastie.org/private/nmvqtauyle3s19wgvbdd7w
Dec 07 11:37:01 <morphis> GNUtoo: you get a IPC_GPRS_IP_CONFIGURATION so PDP context is up
Dec 07 11:37:04 <GNUtoo> GarthPS, I guess COMMERCIAL_LICENSE is for not putting patent-infridging code in the product(like for instance mp3 encoder/decoder)
Dec 07 11:37:10 <GNUtoo> ok thanks
Dec 07 11:37:17 <GNUtoo> I just need to listen to the IP then
Dec 07 11:37:37 <GNUtoo> JaMa, am I right about COMMERCIAL_LICENSE?
Dec 07 11:37:53 <GarthPS> yeah I was thinking about that ..
Dec 07 11:38:30 <morphis> GNUtoo: yes and set the IP + dns servers according to the content of the IP_CONFIGURATION_MESSAGE like I did in FSO
Dec 07 11:38:54 <GNUtoo> yes I'll do that
Dec 07 11:39:04 <GNUtoo> altough I'll commit the gta02 stuff before
Dec 07 11:39:34 <morphis> ok
Dec 07 11:39:46 <JaMa> GNUtoo: yes something like that
Dec 07 11:40:09 <JaMa> GarthPS: to select fetch2 instead of older fetch1 implementation (which is not supported by oe-core)
Dec 07 11:41:08 <GarthPS> ok thx
Dec 07 11:48:12 <mrmoku> dos1: yo, you rock :-)
Dec 07 11:53:22 <morphis> GNUtoo: <morphis> ok, do you know where?
Dec 07 11:55:00 <GNUtoo> no I don't, I'll look after mplayer + data in replicant
Dec 07 11:55:47 <CIA-82> SHR: 03Martin.Jansa 07meta-smartphone * rb7d48436e4bc 10/meta-shr/recipes-shr/images/shr-image.inc: shr-image: drop opkg, it should be pulled based on IMAGE_FEATURES
Dec 07 11:55:49 <CIA-82> SHR: 03Martin.Jansa 07meta-smartphone * ra25077559938 10/meta-shr/recipes-shr/3rdparty/ (emtooth2/add.evas.ecore.patch emtooth2_svn.bb): emtooth2: bump SRCREV again and drop applied patch
Dec 07 11:57:47 <morphis> GNUtoo: ok
Dec 07 11:58:36 <dos1> pabs3: http://build.shr-project.org/tests/site/MISO-info.txt
Dec 07 12:03:43 <CIA-82> SHR: 03Martin.Jansa 07meta-smartphone * r2d8026e5091b 10/meta-shr/recipes-shr/3rdparty/emtooth2_svn.bb: emtooth2: bump SRCREV again and drop applied patch
Dec 07 12:08:42 <pabs3> dos1: I see, not something that could ever go into Debian then
Dec 07 12:14:15 <mrmoku> mickey_office: any suggestion what we could do about our 'fsodeviced comes too late to load firmware' problem?
Dec 07 12:15:16 <morphis> mrmoku: what means fsodeviced comes too late?
Dec 07 12:15:43 <mrmoku> morphis: modules being loaded and requesting firmware before fsodeviced is around
Dec 07 12:16:25 <mrmoku> sure we can try to move fsodeviced to start a tad earlier or module loading to come a bit later
Dec 07 12:16:38 <mrmoku> dunno if that is the correct solution generally speaking
Dec 07 12:17:02 <morphis> hm
Dec 07 12:17:08 <morphis> about whic modules we're talking here?
Dec 07 12:17:28 <mrmoku> on n900 it is etk8...
Dec 07 12:17:32 <JaMa> or let modules and fsodeviced start in paralel :)
Dec 07 12:18:58 <morphis> hm
Dec 07 12:19:09 <morphis> etk8 is required for network?
Dec 07 12:20:14 <mrmoku> I don't think so
Dec 07 12:20:44 <mrmoku> morphis: I'm more concerned in general
Dec 07 12:20:59 <mrmoku> what if fsodeviced needs some module for some plugin?
Dec 07 12:21:08 <mrmoku> then we would have to load modules first
Dec 07 12:21:11 <mrmoku> and then fsodeviced
Dec 07 12:21:21 <morphis> yes but if the module requires a firmware then ..
Dec 07 12:21:24 <morphis> we have a problem
Dec 07 12:21:26 <morphis> you are right
Dec 07 12:21:31 <mrmoku> that's the point, yeah
Dec 07 12:21:40 <morphis> maybe we need something like a deffered plugin loading
Dec 07 12:22:03 <mrmoku> or exctract the firmware loader into a small thing on it's own
Dec 07 12:22:07 <morphis> yes
Dec 07 12:22:11 <morphis> but for the moment
Dec 07 12:22:19 <morphis> who requires the etk8 module?
Dec 07 12:22:25 <pabs3> isn't udev the thing for loading firmware?
Dec 07 12:22:27 <morphis> so we can decide what we can do for the moment
Dec 07 12:22:31 <morphis> pabs3: not in SHR
Dec 07 12:22:37 <morphis> we're not using udev anymore
Dec 07 12:22:52 <pabs3> huh, why is that?
Dec 07 12:23:56 <morphis> as we're using devtmpfs + fsodeviced for that
Dec 07 12:24:03 <morphis> fsodeviced has a firmware loader
Dec 07 12:25:34 <mrmoku> 2011-12-04T12:42:03.247772Z [ERROR] KernelCpuResource <CPU>: Could not register CPU with ousaged: Error calling StartServiceByName for org.freesmartphone.ousaged: GDBus.Error:org
Dec 07 12:25:38 <mrmoku> .freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/libexec/dbus-daemon-launch-helper: Success; trying to enable the resource unconditionally
Dec 07 12:25:59 <mrmoku> root@nokia900:~# ls -l /usr/libexec/dbus-daemon-launch-helper 
Dec 07 12:25:59 <mrmoku> -rwsr-xr--    1 root     root        185056 Nov 21 07:02 /usr/libexec/dbus-daemon-launch-helper
Dec 07 12:26:02 <mrmoku> damn
Dec 07 12:26:05 <morphis> :)
Dec 07 12:26:30 <mrmoku> JaMa: that explains the backlight problem I think
Dec 07 12:28:54 <JaMa> mrmoku: not for me as I was extracting image with --numeric-owner
Dec 07 12:29:15 <JaMa> -rwsr-xr-- 1 root messagebus 185056 Nov 20 12:42 /usr/libexec/dbus-daemon-launch-helper
Dec 07 12:30:10 <mrmoku> JaMa: I have that --numeric-owner in my install script too
Dec 07 12:30:26 <JaMa> which image did you took?
Dec 07 12:30:27 <JaMa> 003?
Dec 07 12:30:31 <mrmoku> and fixing the permissions and restarting fsodeviced makes the backlight work
Dec 07 12:30:34 <mrmoku> yeah 0003
Dec 07 12:30:34 <mrmoku> -0
Dec 07 12:31:37 <JaMa> hmm right it's wrong in http://build.shr-project.org/shr-core-staging/003/images/nokia900/shr-lite-20111204-nokia900-testlab/files-in-image.txt
Dec 07 12:31:45 <mrmoku> JaMa: -rwsr-xr--  1 root root 185056 Nov 21 08:02 dbus-daemon-launch-helper
Dec 07 12:31:48 <mrmoku> yeah :)
Dec 07 12:32:49 <JaMa> and http://build.shr-project.org/shr-core-staging/003/images/om-gta02/shr-lite-20111204-om-gta02-testlab/files-in-image.txt is right
Dec 07 12:33:03 * JaMa killling 004 image build
Dec 07 12:33:15 <mickey_office> mrmoku: can you recap the problem for me? missing context
Dec 07 12:33:22 <mickey_office> ah, i guess i know
Dec 07 12:33:29 <mickey_office> fsodevice not started @ module loading time?
Dec 07 12:33:36 <mrmoku> mickey_office: fsodeviced is needed when modules are loaded that request a firmware
Dec 07 12:33:38 <mickey_office> only one solution there… start it earlier.
Dec 07 12:33:39 <mrmoku> yeah, exactly
Dec 07 12:33:54 <mrmoku> on the other hand fsodeviced might need a module for some plugin
Dec 07 12:34:07 <morphis> mickey_office: good you are here
Dec 07 12:34:07 <mrmoku> some kind of hen-egg thingie
Dec 07 12:34:15 <mickey_office> mrmoku: not much of a problem
Dec 07 12:34:32 <mickey_office> we can teach fsodeviced to rerun a detection phase when a new module is loaded
Dec 07 12:34:36 <mickey_office> it can detect that via kobject
Dec 07 12:35:26 <mrmoku> oh, diego woke up... brb
Dec 07 12:36:58 <morphis> mickey_office: you have some time right now for the vala things?
Dec 07 12:37:42 <mrmoku> mickey_office: ok
Dec 07 12:40:07 <JaMa> mrmoku: I think I've found the problem with dbus owner in sstate (missing --numeric-owner there too)
Dec 07 12:40:16 <mrmoku> JaMa: great
Dec 07 12:43:28 <mickey_office> morphis: yo
Dec 07 12:45:04 <mrmoku> rc0.d/K27fsodeviced  rc1.d/K27fsodeviced  rc2.d/S27fsodeviced  rc3.d/S27fsodeviced  rc4.d/S27fsodeviced  rc5.d/S27fsodeviced  rc6.d/K27fsodeviced
Dec 07 12:45:09 <mrmoku> rcS.d/S04modutils.sh
Dec 07 12:45:11 <radekp> mrmoku: you can embed firmware to modules, if you dont have licensing problem with that
Dec 07 12:45:13 <mrmoku> rc0.d/K20dbus-1  rc1.d/K20dbus-1  rc2.d/S02dbus-1  rc3.d/S02dbus-1  rc5.d/S02dbus-1  rc6.d/K20dbus-1
Dec 07 12:45:38 <mrmoku> radekp: hmm... I think we would have issues with that
Dec 07 12:46:36 <mrmoku> would be the most elegant solution though :)
Dec 07 12:47:38 <mrmoku> mickey_office: would it be feasible to make fsodeviced start without dbus? and detect when dbus gets started?
Dec 07 12:47:43 <morphis> mickey_office: so with which one do we want to start?
Dec 07 12:48:07 <radekp> also starting "udevd", then modprobe "module_which_needs_fw", kill udevd was working
Dec 07 12:48:19 <mrmoku> :P
Dec 07 12:48:24 <mrmoku> radekp: that I call a hack ;)
Dec 07 12:48:29 * radekp too :)
Dec 07 12:48:43 <radekp> but i think you can write small program that just calls libudev
Dec 07 12:49:05 <radekp> IIRC udev is written as library, you can use it just for FW loading
Dec 07 12:49:34 * radekp has the same problem on QtMoko
Dec 07 12:49:40 <mrmoku> yeah, but before we do that we could extract fsodeviceds firmware loader
Dec 07 12:49:46 <mrmoku> radekp: hmm... interesting
Dec 07 12:50:32 <radekp> i am also not using normal udev anymore
Dec 07 12:50:33 <mrmoku> radekp: we should find a solution then that works for you too
Dec 07 12:50:39 <mrmoku> yeah, we neither
Dec 07 12:50:50 <mrmoku> are you using fsodeviced?
Dec 07 12:50:54 <mickey_office> mrmoku: i don't know offhand whether that would work, worth a try
Dec 07 12:51:18 <mrmoku> mickey_office: starting after dbus is a quite limiting factor in moving fsodeviced early :)
Dec 07 12:51:23 <radekp> i have FSO just as optional dependency
Dec 07 12:51:47 <mickey_office> mrmoku: i see. well, i have to think about that
Dec 07 12:51:51 <radekp> i do images based on debian stable, which does not have FSO
Dec 07 12:51:55 <mrmoku> mickey_office: ok :)
Dec 07 12:51:57 <GNUtoo> JaMa, I tought that adding mplayer-common/om-gta02 marked it to machine-arch automatically
Dec 07 12:52:12 <GNUtoo> Architecture: all
Dec 07 12:52:28 <GNUtoo> that's what I have with opkg info mplayer-common on target
Dec 07 12:53:05 <JaMa> did you bump PR or -force-reinstall it?
Dec 07 12:53:34 <JaMa> not sure if inherit all arch doesn't override mplayer-common/om-gta02 in SRC_URI..
Dec 07 12:55:24 <GNUtoo> ok
Dec 07 12:55:53 <GNUtoo> I'll machine arch it for om-gta02 and retry then
Dec 07 12:56:04 <mickey_office> morphis: lets start with the question about the state of master and vala-014-support branch and about the problems with vala 0.14.x, x<=2 you found.
Dec 07 12:56:06 <radekp> mrmoku: maybe you could load the module which needs firmware when FSO is started
Dec 07 12:56:23 <radekp> mrmoku: and fso can then supply the fw
Dec 07 12:56:26 <JaMa> GNUtoo: it's in meta-openmoko right?
Dec 07 12:56:40 <radekp> mrmoku: instead of making FSO start sooner, you can load the module later :)
Dec 07 12:56:49 <mickey_office> well
Dec 07 12:57:01 <mickey_office> given that FSO on some platforms perform quite critical things, starting fsodeviced at least soon is a good idea
Dec 07 12:57:06 <mickey_office> (think battery charging….)
Dec 07 12:57:18 <GNUtoo> yes
Dec 07 13:00:54 <mickey_office> then again, i can offer you another alternative
Dec 07 13:01:01 <mickey_office> we create fsosystemd
Dec 07 13:01:08 <mrmoku> :)
Dec 07 13:01:09 <mickey_office> and put all the non-dbus system service plugins in there
Dec 07 13:01:13 <mickey_office> like charging
Dec 07 13:01:15 <mickey_office> firmware loading
Dec 07 13:01:16 <mickey_office> and what not
Dec 07 13:01:24 <mrmoku> init too?
Dec 07 13:01:28 <mickey_office> i think that would be a clean solution
Dec 07 13:01:33 <mickey_office> ya, why not, it would belong there
Dec 07 13:01:56 <mrmoku> how much work is it?
Dec 07 13:02:03 <morphis> mickey_office: state of master branch regarding vala is ok, everything should work back again
Dec 07 13:02:20 <morphis> mickey_office: we had some problems with the changed behaviour of supplying structs as parameters
Dec 07 13:02:33 <morphis> which does not lead to compilation error but to runtime errors
Dec 07 13:02:36 <morphis> that is fixed
Dec 07 13:02:43 <mickey_office> well, the init stuff is a more complex task, but we could start with the other things, that would be easy
Dec 07 13:02:59 <morphis> 0.14.1 does not include the fixes we need
Dec 07 13:03:23 <morphis> I already talked to luca bruno about getting my fixes into 0.14.2 and he is reviewing my changes
Dec 07 13:03:26 <mickey_office> morphis: hmm, so you merged the 014-support to cornucopia-master?
Dec 07 13:03:38 <morphis> after the problems were gone, yes
Dec 07 13:03:43 <mickey_office> hmm
Dec 07 13:03:44 <mickey_office> ok
Dec 07 13:03:50 <morphis> master is usable now with 0.14.1.7-....
Dec 07 13:03:56 <mickey_office> that means i must fix / revert 
Dec 07 13:04:01 <mickey_office> the things that i don't like
Dec 07 13:04:07 <morphis> which is here http://downloads.freesmartphone.org/vala-0.14.1.7-3673f.tar.bz2
Dec 07 13:04:13 <morphis> yes
Dec 07 13:04:56 <mickey_office> hmm, ok
Dec 07 13:05:37 <morphis> I pulled playya__ mdbus2 gbus porting patches in
Dec 07 13:05:41 <morphis> after some testing and fixes
Dec 07 13:06:56 <mickey_office> mrmoku: the basic idea would be that fsosystemd will be a usual fso daemon and optionally (later) would also contain init behaviour, if started as pid 1
Dec 07 13:07:25 <morphis> mickey_office: but please fix the things you don't like
Dec 07 13:07:47 <radekp> mrmoku: btw do you remember why SHR dropped udev?
Dec 07 13:07:51 <mickey_office> morphis: i need to catch up with vala to see whether there are alternatives at all, perhaps the introduction of all the * and ** is without alternatives
Dec 07 13:08:06 <JaMa> radekp: it was much slower then devtmpfs is
Dec 07 13:08:20 <mickey_office> radekp: because it's slow and cumbersome and eats kittens. and devtempfs is almost a full substitute for it
Dec 07 13:08:25 <JaMa> radekp: see bootcharts http://build.shr-project.org/tests/jama/
Dec 07 13:08:49 <radekp> i think the problem with udev is that it touches all the uevent files on startup
Dec 07 13:09:11 <radekp> which is slow, but if this could be disabled, then it could be ok
Dec 07 13:10:24 <radekp> IIRC i did it because of speed too, but i think the slowness is just because that it goes through all uevent files in /sys and touches the uevent so that kernel sends device info on netlink
Dec 07 13:11:27 <radekp> otherwise udevd should be quite lightweight - it's written in pure C, it has 120kb here
Dec 07 13:11:48 <JaMa> it's much better with systemd
Dec 07 13:12:03 <radekp> if i run udevd from command line it's up instantly
Dec 07 13:12:45 <radekp> it starts in 1ms
Dec 07 13:15:10 <CIA-82> SHR: 03GNUtoo 07meta-smartphone * r6c1b312888fd 10/meta-openmoko/recipes-multimedia/mplayer/ (mplayer-common.bbappend mplayer-common/om-gta02/mplayer.conf): meta-openmoko: override mplayer.conf for om-gta02
Dec 07 13:15:31 <dos1|N900> JaMa, mrmoku: ping
Dec 07 13:15:47 <dos1|N900> we'll need some option to be set in apache conf for our vhost
Dec 07 13:16:13 <dos1|N900> IndexOptions +SuppressHTMLPreamble
Dec 07 13:16:33 <mrmoku> mickey_office: ok, maybe I take a look
Dec 07 13:16:45 <mrmoku> dos1|N900: pong
Dec 07 13:17:15 <dos1|N900> i would set it in .htaccess, but its parsing is disabled
Dec 07 13:17:20 <mickey_office> mrmoku: cool. it would help me if you just create the daemon and move the plugins from fsodeviced to fsosystemd
Dec 07 13:17:20 <mrmoku> dos1|N900: is that a option that can be set via .htaccess?
Dec 07 13:17:38 <mickey_office> mrmoku: i'm still interested to work on the init system
Dec 07 13:17:40 <mrmoku> mickey_office: yeah... that should be inside my skills :P
Dec 07 13:17:42 <mickey_office> :)
Dec 07 13:17:43 <dos1|N900> mrmoku: ^^
Dec 07 13:17:53 <mrmoku> dos1|N900: ok
Dec 07 13:18:28 <mrmoku> dos1|N900: would we prefer turning on .htaccess parsing?
Dec 07 13:18:50 <mrmoku> or just get that IndexOptions in the conf
Dec 07 13:18:52 <dos1|N900> it's not critical, but you can see on your own what mess is in html code of my page
Dec 07 13:19:13 <dos1|N900> mrmoku: turning on .htaccess would be much more flexible for us in the future :D
Dec 07 13:20:00 <mrmoku> ok
Dec 07 13:20:33 * mrmoku has to do a longer daywork phone call first and will then see to get some bearstech contact
Dec 07 13:20:43 <dos1|N900> ok, thx
Dec 07 13:21:07 <dos1|N900> (.htaccess is already on its place, patiently waiting to be respected :))
Dec 07 13:21:13 <mrmoku> :)
Dec 07 13:26:20 <GarthPS> does someone know why libmad is not pulled when building vlc ?  even if COMMERCIAL_LICENSE is defined? I don't get the  ${@base_conditional of vlc.inc
Dec 07 13:30:00 <morphis> mrmoku: there is already the fsoinitd which you can use as base for fsosystemd
Dec 07 13:30:18 <mrmoku> morphis: yeah, will mix it alltogether :)
Dec 07 13:30:28 <morphis> but disable the init part :)
Dec 07 13:30:35 <mrmoku> sure :P
Dec 07 13:33:13 <mrmoku> dos1|N900: is enabled now
Dec 07 13:39:06 <mrmoku> radekp: btw. regarding charging on gta04... you have twl4030_charger.allow_usb=1 in your cmdline?
Dec 07 13:52:58 <GNUtoo> GarthPS, please paste the full command
Dec 07 13:53:07 <GNUtoo> s/command/line
Dec 07 13:53:19 <GNUtoo> (the @base_conditional
Dec 07 13:53:20 <GNUtoo> )
Dec 07 13:54:16 <GarthPS> GNUtoo: DEPENDS = "libfribidi libtool libgcrypt gst-plugins-bad virtual/libsdl qt4-x11-free dbus libxml2 gnutls tremor faad2 ffmpeg flac \
Dec 07 13:54:16 <GarthPS> "
Dec 07 13:54:16 <GarthPS> #           ${@base_conditional('ENTERPRISE_DISTRO', '1', '', 'libmad libid3tag liba52 mpeg2dec', d)}"
Dec 07 13:54:43 <GNUtoo> GarthPS, if entreprise distro is 1 then add '' as dependences, else add 'libmad etc....'
Dec 07 13:54:48 <GNUtoo> that's what it does
Dec 07 13:55:02 <GNUtoo> and there is a comment before also
Dec 07 13:55:05 <GNUtoo> so remove the comment
Dec 07 13:55:14 <GarthPS> So for me right now vlc_1.1.11 is broken as it does not build if you don't build libmad before
Dec 07 13:55:16 <GNUtoo> but it'll surely fail with lacking recipes
Dec 07 13:55:22 <GNUtoo> yes
Dec 07 13:55:29 <GNUtoo> GarthPS, what about mplayer?
Dec 07 13:56:30 <GarthPS> GNUtoo: why it is commented  ? mplayer did not tried yet
Dec 07 13:56:54 <GNUtoo> because I guess that some recipes were not in core based oe at the time
Dec 07 13:57:21 <GNUtoo> some of the dependencies like libmmad etc...
Dec 07 13:57:38 <GNUtoo> GarthPS, oe-core still lacks a lot of recipes
Dec 07 13:57:55 <GarthPS> GNUtoo: well libmad is there now 
Dec 07 13:57:58 <GNUtoo> and I really don't have the time to add them back
Dec 07 13:58:12 <GNUtoo> yes so try uncommenting that line and see what's still lacking
Dec 07 13:58:20 <GarthPS> GNUtoo:  I will tell you if the comment can be removed
Dec 07 13:58:30 <GarthPS> trying to build vlc right now
Dec 07 13:58:36 <GNUtoo> if so send a patch
Dec 07 13:58:46 <GNUtoo> or push if you have push access
Dec 07 14:00:05 <GarthPS> GNUtoo: ok I will (don't have right access)
Dec 07 14:00:14 <GNUtoo> ok
Dec 07 14:00:14 <GarthPS> or write access :)
Dec 07 14:00:20 <GNUtoo> ok
Dec 07 14:02:23 <JaMa> GarthPS: please send it directly to OE-devel ML as written in README of meta-oe layer ;)
Dec 07 14:02:47 <radekp> mrmoku: is that needed?
Dec 07 14:04:03 <JaMa> GarthPS: also read this thread http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-September/034954.html
Dec 07 14:04:47 <mrmoku> radekp: yup, with 3.x it is needed to enable charging
Dec 07 14:04:57 <mrmoku> did not try the wall charger as I can't find it :P
Dec 07 14:05:09 <mrmoku> but for charging via usb I need that
Dec 07 14:05:56 <radekp> mrmoku: cool thanks, i'll try
Dec 07 14:06:01 <mrmoku> yw
Dec 07 14:20:49 <dos1|N900> mrmoku: great, thanks :)
Dec 07 14:20:57 <dos1|N900> it works \o/
Dec 07 14:42:24 <mrmoku> dos1|N900: good :)
Dec 07 15:23:32 <angelox|laptop> dos1: wow, fantastic working site :)
Dec 07 16:00:55 <dos1> i've flashed shr-aurora on gta02
Dec 07 16:01:06 <dos1> how to turn off the device correctly? xD
Dec 07 16:01:17 <angelox|laptop> wopps we forgot that part :)
Dec 07 16:02:05 <angelox|laptop> when i had my n900 i turned off using ssh :)
Dec 07 16:03:01 <mrmoku> dos1: just use the battery switch ;)
Dec 07 16:19:20 <Ainulindale> aurora ?
Dec 07 16:19:22 <Ainulindale> what's that?
Dec 07 16:26:08 <mrmoku> Ainulindale: framebuffer, qt based feature phone flavour
Dec 07 16:26:25 <mrmoku> mainly invented by morphis and mickey_office to have a simple testbed for fso
Dec 07 16:31:15 <angelox|laptop> wow, morphis was there and i did not see :)
Dec 07 16:31:28 <angelox|laptop> morphis: http://wiki.freesmartphone.org/index.php/Aurora/Screenshots
Dec 07 16:34:14 <mrmoku> root@om-gta04:~# opkg install fsosystemd
Dec 07 16:34:14 <mrmoku> Installing fsosystemd (0.0.1+gitr1+20a9ce696d738036c41298a1e185696cc701ec8f-r6.0) to root...
Dec 07 16:34:17 <mrmoku> Downloading http://ladyt/shr-core/ipk//armv7a-vfp-neon/fsosystemd_0.0.1+gitr1+20a9ce696d738036c41298a1e185696cc701ec8f-r6.0_armv7a-vfp-neon.ipk.
Dec 07 16:34:20 <mrmoku> Configuring fsosystemd.
Dec 07 16:40:17 <angelox|laptop> Successfully? :)
Dec 07 16:43:13 <GNUtoo> what's fsosystemd?
Dec 07 16:44:14 <GNUtoo> I don't see it in cornucopia
Dec 07 16:44:16 <GNUtoo> pespin, hi
Dec 07 16:44:49 <dos1> ok, i've played a bit with aurora on gta02
Dec 07 16:44:58 <pespin> hi! finally I have conn from a mobile's friend sharing it hehe
Dec 07 16:45:01 <dos1> now flashing shr-shr :D
Dec 07 16:45:02 <GNUtoo> dos1, how is it?
Dec 07 16:45:19 <dos1> GNUtoo: awfuuuuuuuullyyyy sloooooooooooow
Dec 07 16:45:26 <GNUtoo> ah ok
Dec 07 16:45:40 <dos1> GNUtoo: and nonuseable anyway :D there's something wrong with telephony
Dec 07 16:45:50 <GNUtoo> ah again?
Dec 07 16:46:04 <GNUtoo> maybe something is wrong
Dec 07 16:46:11 <GNUtoo> last time I looked it was not that slow
Dec 07 16:46:13 <dos1> outgoing call was displayed as incoming
Dec 07 16:46:16 <GNUtoo> but it was unusable the same
Dec 07 16:46:17 <GNUtoo> ok
Dec 07 16:46:33 <dos1> truly incoming call couldn't be rejected nor accepted
Dec 07 16:47:31 <GNUtoo> dos1, when was the build from?
Dec 07 16:47:42 <mrmoku> GNUtoo: have to push it
Dec 07 16:47:51 <GNUtoo> ok
Dec 07 16:47:53 <mrmoku> GNUtoo: it will solve the firmware loading problem
Dec 07 16:47:56 <mrmoku> as a first step
Dec 07 16:48:10 <GNUtoo> ah? but we have fsodeviced for that
Dec 07 16:48:14 <dos1> GNUtoo: 004
Dec 07 16:48:18 <GNUtoo> with firmware loader
Dec 07 16:48:21 <GNUtoo> dos1, ok
Dec 07 16:48:27 <mrmoku> GNUtoo: yeah, but the problem with that is a hen - egg one
Dec 07 16:48:29 <dos1> added report to wiki
Dec 07 16:48:37 <mrmoku> fsodeviced might need a module for a plugin
Dec 07 16:48:44 <mrmoku> and modules need fsodeviced as firmware loader
Dec 07 16:49:05 <GNUtoo> ok
Dec 07 16:50:01 <mrmoku> GNUtoo: all essential and basic low-level device stuff that does not need dbus should go there
Dec 07 16:50:13 <mrmoku> like the n900 charging plugin too
Dec 07 16:50:14 <GNUtoo> ok
Dec 07 16:52:51 <antrik> GNUtoo: I'm still using u-boot on GTA02. not sure where I got it from though... probably not SHR
Dec 07 16:54:11 <GNUtoo> ok
Dec 07 16:57:58 <morphis> mrmoku: no, it's not framebuffer restricted and currently we're using x11
Dec 07 16:59:52 <mrmoku> morphis: ohh... didn't know that
Dec 07 16:59:56 <mrmoku> Ainulindale: ^^
Dec 07 17:00:02 <morphis> mrmoku: no problem
Dec 07 17:00:17 <morphis> mrmoku, Ainulindale: so Aurora is SHR without E17 UI but with Qt based UI
Dec 07 17:00:24 <mrmoku> morphis: I have a fsosystemd now
Dec 07 17:00:39 <mrmoku> I'm wondering about what plugins can move there though
Dec 07 17:01:10 <mrmoku> the n900 charging plugin has a comment     // internal (accessible for aggregate power supply)
Dec 07 17:01:23 <mrmoku> which tells me it can't go to fsosystemd probably
Dec 07 17:01:48 <mrmoku>     public async FreeSmartphone.Device.PowerStatus get_power_status() throws DBusError, IOError
Dec 07 17:01:50 <morphis> mrmoku: whats the general idea about fsosystemd?
Dec 07 17:01:51 <mrmoku> yeah
Dec 07 17:02:05 <morphis> I thought it should be carry only system stuff and not device things
Dec 07 17:02:16 <morphis> like firmware handling
Dec 07 17:02:18 <mrmoku> first step to have the essential critical stuff
Dec 07 17:02:19 <mrmoku> yeah
Dec 07 17:02:25 <mrmoku> there's not much to go there
Dec 07 17:02:31 <mrmoku> charging would have been a nice one though
Dec 07 17:02:37 <morphis> really?
Dec 07 17:02:40 <mrmoku> the earlier we can charge the better
Dec 07 17:02:45 <morphis> hm
Dec 07 17:02:59 <morphis> we have the power supply dbus API
Dec 07 17:03:01 <mrmoku> anyway... will just push it with the firmware loader 
Dec 07 17:03:05 <morphis> ok
Dec 07 17:03:13 <mrmoku> yeah, but you can't enable/disable charging there
Dec 07 17:03:22 <morphis> I thing fsosystemd should carry only some little system stuff
Dec 07 17:03:39 <morphis> yes
Dec 07 17:03:47 <morphis> thats some feature we should really implement
Dec 07 17:03:58 <mrmoku> enable disable charging?
Dec 07 17:03:59 <mrmoku> why that
Dec 07 17:04:22 <morphis> for example: you're in the train, laptop battery is low
Dec 07 17:04:35 <morphis> and you connect your phone to have internet access via usb
Dec 07 17:04:45 <morphis> then the phone should not charge over USB
Dec 07 17:04:56 <mrmoku> hmm
Dec 07 17:05:01 <mrmoku> that would be a usecase
Dec 07 17:05:07 <morphis> but it's not really important :)
Dec 07 17:05:11 <mrmoku> no :P
Dec 07 17:05:15 <morphis> we have more important use cases 
Dec 07 17:05:24 <morphis> ok, so we have a fsosystemd now
Dec 07 17:05:35 <morphis> do you converted the fsoinitd to be plugin-based?
Dec 07 17:06:00 <morphis> hm I dropped fsoinitd some time ago ...
Dec 07 17:06:14 <mrmoku> well in the end it's taken more from fsodeviced
Dec 07 17:06:33 <mrmoku> when I saw fsoinitd has no plugin stuff :)
Dec 07 17:06:42 <morphis> ok
Dec 07 17:07:01 <morphis> but I am not sure wether fsosystemd should provide a dbus API
Dec 07 17:07:39 <mrmoku> no it can't 
Dec 07 17:07:51 <mrmoku> well it could, but not on startup
Dec 07 17:08:17 <mrmoku> dbus starts way too late
Dec 07 17:08:35 <morphis> yes
Dec 07 17:08:58 <morphis> btw. I started to implement a test suite for our dbus API
Dec 07 17:09:15 <morphis> which you can run and you have a report at the end which stuff works as it should and which not
Dec 07 17:09:33 <mrmoku> nice
Dec 07 17:09:46 <morphis> would also help to adjust different implementations like in the GSM domain
Dec 07 17:09:48 <morphis> yes
Dec 07 17:10:08 <morphis> it's something we really need even with the aim to get a stable distribution
Dec 07 17:10:36 <dos1> JaMa: shr-full-om-gta02.ubi from 004 does not mount
Dec 07 17:11:09 <dos1> JaMa: UBI error: process_eb: bad image sequence number 1880304218 in PEB 1969, expected 1537023111
Dec 07 17:11:34 <dos1> downloading lite now
Dec 07 17:11:40 <dos1> (btw. aurora ubi image worked)
Dec 07 17:11:58 <morphis> dos1: aurora in the gta02?
Dec 07 17:12:06 <dos1> morphis: yup
Dec 07 17:12:16 <morphis> does it startup the UI?
Dec 07 17:12:25 <dos1> yup
Dec 07 17:12:30 <dos1> it's awwwfuuulllyyyy sloooooow
Dec 07 17:12:35 <dos1> and has problems with telephony
Dec 07 17:12:42 <dos1> but it starts and somehow works
Dec 07 17:14:53 * mrmoku dinner
Dec 07 17:15:45 <morphis> dos1:  :)
Dec 07 17:16:18 <morphis> yes latest version (004) has problems with telephony but they are fixed and 005 should be working
Dec 07 17:16:44 <JaMa> morphis: ?
Dec 07 17:16:46 <angelox|laptop> morphis: should it be so slow?
Dec 07 17:18:44 <angelox|laptop> morphis: and that is cpp version?
Dec 07 17:20:18 <GNUtoo> pespin, hi did I say that I fixed mplayer for ogg vorbis on om-gta02?
Dec 07 17:20:47 <pespin> GNUtoo, nop, I didn't know
Dec 07 17:20:54 <pespin> GNUtoo, mplayer2 or 1?
Dec 07 17:20:59 <dos1> JaMa: the same problem with lite :(
Dec 07 17:21:00 <pespin> 2 right?
Dec 07 17:21:03 <GNUtoo> both I guess
Dec 07 17:21:09 <GNUtoo> the fix is in mplayer-config
Dec 07 17:21:14 <GNUtoo> so I tried with mplayer2
Dec 07 17:21:19 <GNUtoo> but maybe it fixes 1 too
Dec 07 17:21:23 <pespin> GNUtoo, hmm wait, wasn't your problem with gstreamer?
Dec 07 17:21:33 <GNUtoo> I've many problems.....
Dec 07 17:21:36 <pespin> getting noise instead of music
Dec 07 17:21:37 <pespin> lol
Dec 07 17:21:57 <GNUtoo> one of the problem is mplayer not playing well ogg vorbis => fixed in git
Dec 07 17:22:05 <pespin> GNUtoo, buy an ukelele, I did it some days before and it helps to follow the happiness path ;)
Dec 07 17:22:12 <GNUtoo> other problems include n900 not working well for instance
Dec 07 17:22:18 <GNUtoo> lol
Dec 07 17:22:33 <JaMa> dos1: did you use dfu-util or cleaned and flashed from uSD?
Dec 07 17:22:42 <dos1> JaMa: dfu-util
Dec 07 17:23:04 <JaMa> pespin: can you please apply the BINDINGS/vala patch to fix label_set _before_ the big merge with API from your 2nd repo?
Dec 07 17:23:31 <dos1> flashing aurora worked, flashing shr-lite or shr-full didn't
Dec 07 17:23:34 <GNUtoo> pespin, or maybe I should write a jamendo app for the om-gta02
Dec 07 17:23:41 <pespin> JaMa, apply it in E svn?
Dec 07 17:23:44 <JaMa> pespin: yes
Dec 07 17:23:55 <pespin> JaMa, do you have patch at hand?
Dec 07 17:24:06 <pespin> as I modified it to apply for newer eflvala
Dec 07 17:24:11 <JaMa> pespin: so we will be able to stay with some E svn SRCREV (without extra patch) until all apps are fixed
Dec 07 17:24:33 <pespin> ok
Dec 07 17:24:48 <JaMa> pespin: http://git.openembedded.org/meta-openembedded/tree/meta-efl/recipes-efl/efl/libeflvala/0001-BINDINS-vala-update-genlist-gengrid-callbacks-s-labe.patch but please review
Dec 07 17:25:13 <morphis> JaMa: I think 005 will be the next staging version and it includes my latest commit for meta-smartphone which bumps aurora SRCREV
Dec 07 17:25:26 <pespin> GNUtoo, I haven't played with jamendo yey, is it good?
Dec 07 17:25:27 <morphis> angelox|laptop: it's the graphic stuff which is so slow on the om-gta02
Dec 07 17:25:40 <GNUtoo> pespin, very, I've a jamendo app on replicant
Dec 07 17:25:50 <JaMa> morphis: 004 will have it (it wasn't closed yet)
Dec 07 17:25:52 <GNUtoo> (the music is very good)
Dec 07 17:26:03 <angelox|laptop> morphis: ah ok
Dec 07 17:26:07 <JaMa> morphis: and I'm rebuilding those images atm, because of dbus issue
Dec 07 17:26:14 <morphis> ah ok
Dec 07 17:26:18 <morphis> then it will be 004
Dec 07 17:26:35 <pespin> GNUtoo, only free music right?
Dec 07 17:26:51 <GNUtoo> freely redistributable yes
Dec 07 17:26:59 <JaMa> actualy I've removed oll older images for armv7 because they all had wrong dbus owner :/
Dec 07 17:27:05 <GNUtoo> creative commons and some other licenses
Dec 07 17:27:20 <GNUtoo> but as you know CC have stuff like ND NC etc....
Dec 07 17:27:36 <GNUtoo> but redistributable is good enough for me
Dec 07 17:27:49 <pespin> nice
Dec 07 17:27:58 <pespin> GNUtoo, lots of classical music I guess?
Dec 07 17:28:11 <GNUtoo> there is some classical
Dec 07 17:28:18 <GNUtoo> not only classical
Dec 07 17:28:30 <GNUtoo> for classical there is also another website
Dec 07 17:28:35 <pespin> I guess most of classical music is under public domain right now right?
Dec 07 17:28:37 <GNUtoo> musopen
Dec 07 17:28:41 <GNUtoo> yes
Dec 07 17:28:50 <GNUtoo> but jamendo has everything, not only classical
Dec 07 17:28:52 <pespin> ok :)
Dec 07 17:29:06 <pespin> does it have some kinf of API or webservice?
Dec 07 17:29:37 <GNUtoo> yes it does
Dec 07 17:29:47 <GNUtoo> else the jamendo app wouldn't work
Dec 07 17:30:01 <GNUtoo> also there is jamendo integrated in many desktop clients
Dec 07 17:30:03 <GNUtoo> like totem
Dec 07 17:30:08 <GNUtoo> or rythmbox
Dec 07 17:30:44 <antrik> JaMa: err... are you seriously considering dropping some of the most basic phone applications from the feed? I wonder what your purpose is with SHR, if you don't care about having an actual phone UI?...
Dec 07 17:31:05 <JaMa> antrik: like wht?
Dec 07 17:31:16 <GNUtoo> basically on jamendo you won't find a lot of interpretation of classical music but rather new songs including classical ones
Dec 07 17:31:39 <GNUtoo> (for interpretation of classical stuff there is wikipedia, musopen etc...)
Dec 07 17:31:42 <pespin> nice, I'd give a try but I have enough stuff to do with emtooth2 and etalk and all this eflvala shit.
Dec 07 17:31:47 <GNUtoo> ok
Dec 07 17:31:58 <GNUtoo> maybe just listen to the music in a desktop client then
Dec 07 17:32:12 <pespin> yeah :)
Dec 07 17:33:17 * JaMa going home, bbl
Dec 07 17:47:15 <pespin> JaMa, I had to hack manually my Elementary.h as I don't have here in netbook such new elementary.
Dec 07 17:47:29 <pespin> apart from that looks ok, I'll push
Dec 07 17:47:53 <JaMa> good, one less efl patch in meta-efl :)
Dec 07 17:48:07 <antrik> pespin: new recordings of classical music are not at all public domain
Dec 07 17:48:40 <antrik> in fact, considering the time when recordings became common, you will be hard pressed to finde *any* that are public domain...
Dec 07 17:48:45 <pespin> antrik, so the copyright is per recording, not per piece?
Dec 07 17:49:16 <antrik> JaMa: you were talking about ffphonelog and ffalarms
Dec 07 17:49:53 <JaMa> antrik: and did I say I have removed them?
Dec 07 17:50:17 <pespin> JaMa, Committed revision 65990.
Dec 07 17:50:28 <JaMa> pespin: thx
Dec 07 17:51:50 <antrik> pespin: the copyright is on a lot of things; including original composition, arrangement, performance, and even the actual recording I think...
Dec 07 17:52:27 <pespin> ugh what a mess then
Dec 07 17:52:33 <antrik> indeed
Dec 07 17:52:34 <Ainulindale> Hmmm well for the aurora thingy
Dec 07 17:52:49 <Ainulindale> Why not evolve on the SHR stack basis?
Dec 07 17:52:59 <Ainulindale> (and/or fork and/or ditch the current one)
Dec 07 17:53:20 <Ainulindale> (this isn't a trick question)
Dec 07 17:53:55 <Ainulindale> Because at the beginning of SHR the goal was (and hopefully ever is) to do exactly that :-)
Dec 07 17:54:06 <antrik> JaMa: no, but you said that you can drop them instead of adapting for newer eflvala...
Dec 07 17:55:36 <JaMa> antrik: I've said that about apps nobody cares about
Dec 07 17:56:09 <JaMa> antrik: and if you check the logs I've fixed all apps using wrong elm or vala/elm APIs before bumping EFL in OE..
Dec 07 17:56:14 <antrik> Ainulindale: the official justification is that the SHR stack is supposedly to complex for testing FSO
Dec 07 17:56:29 <JaMa> antrik: and I plan to do it again if needed just to be able to use newer EFL if possible
Dec 07 17:56:43 <Ainulindale> I don't care about the stack we're talking about testing features
Dec 07 17:56:59 <Ainulindale> SHR is mainly a distribution with no concern for specific stacks
Dec 07 17:57:15 <Ainulindale> So if the purpose is to test all the features
Dec 07 17:57:26 <antrik> JaMa: well, obviously anyone actually wanting to use it for a phone will care at least about ffphonelog...
Dec 07 17:57:29 <Ainulindale> Then this UI is basically what should have been done (and supposed to be done) 4 years ago :-)
Dec 07 17:57:55 <JaMa> antrik: there there is no issue and I don't understand why you said I plan to remove it
Dec 07 17:58:04 <Ainulindale> That is : sensible, usable and coherent UI for phone functionnalities and settings
Dec 07 17:58:08 <JaMa> s/there there/then there/
Dec 07 17:58:09 <apt> JaMa meant: antrik: then there is no issue and I don't understand why you said I plan to remove it
Dec 07 18:01:09 <antrik> JaMa: well, maybe I misread your statement. it sounded like you considered it a serious option
Dec 07 18:01:17 <antrik> 19:15 < pespin> JaMa, yeah but once I'll move eflvala I have in gitorious to E, apps should be fixed (and will not be only a easy sed command)
Dec 07 18:01:22 <antrik> 19:17 < JaMa> pespin: those apps are pretty simple
Dec 07 18:01:22 <antrik> 19:17 < JaMa> pespin: so if someone still cares they can be fixed even with little more help then easy sed commands
Dec 07 18:01:25 <antrik> 19:18 < JaMa> and if nobody cares then we'll just drop them from feed :)
Dec 07 18:02:02 <antrik> I didn't say you *plan* to remove them... I asked whether you are seriously considering it
Dec 07 18:02:57 <antrik> Ainulindale: I'm not sure what you are trying to say...
Dec 07 18:03:09 <Ainulindale> I'm not trying to say something, I'm saying it :-)
Dec 07 18:03:43 <mrmoku> :)
Dec 07 18:03:52 <Ainulindale> The question is: what is the goal behind the implementation of yet another stack versus enhancing the current one or forking it or any other solution?
Dec 07 18:03:58 <Ainulindale> Is there a specific reasons which would explain that?
Dec 07 18:03:58 <CIA-82> freesmartphone.org: 03mok 07cornucopia * r341524bc4241 10/fsosystemd/ (20 files in 7 dirs): 
Dec 07 18:03:58 <CIA-82> freesmartphone.org: fsosystemd: initial implementation
Dec 07 18:03:58 <CIA-82> freesmartphone.org: Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Dec 07 18:04:26 <mrmoku> the problem seems to be the complexity of the SHR phone stack
Dec 07 18:04:30 <antrik> (BTW, I don't really see the purpose of Aurora either... the UI needs for phone functionality are pretty clear; I see no reason why any new UI would actually be simpler than the existing SHR one...)
Dec 07 18:04:46 <Slyon> hey
Dec 07 18:04:50 <mrmoku> yo Slyon 
Dec 07 18:04:53 <morphis> Ainulindale: it's not a fork
Dec 07 18:05:06 <morphis> Ainulindale: it's just a playground for me and mickeyl 
Dec 07 18:05:10 <Ainulindale> mrmoku: What about the "complexity of the SHR phone stack"?
Dec 07 18:05:24 <Ainulindale> Because this expression sounds to me as a "me don't like C me do other stuff"
Dec 07 18:05:32 <mrmoku> :)
Dec 07 18:05:39 <Ainulindale> Just trying to find out the goal or purpose behind that 
Dec 07 18:05:40 <mrmoku> I'm not the right one to talk with here :P
Dec 07 18:05:46 <Ainulindale> mrmoku: meh
Dec 07 18:05:50 <Ainulindale> mrmoku: you suck! :-)
Dec 07 18:05:55 * mrmoku likes C ;)
Dec 07 18:06:02 <Slyon> mrmoku, can you tell me what the "re"-Regex and the "tere"-Regex needs to describe in a fsogsmd plugin when overwriting an AT command?
Dec 07 18:06:03 <Ainulindale> morphis: well then please enlighten me :-)
Dec 07 18:06:10 <Ainulindale> (bad pun sorry)
Dec 07 18:06:16 <Ainulindale> :->
Dec 07 18:06:30 <mrmoku> Slyon: uhh
Dec 07 18:06:31 <Ainulindale> mrmoku: C is for men!
Dec 07 18:06:33 <mrmoku> not without looking
Dec 07 18:06:34 <morphis> Ainulindale: in general mickeyl and I wanted a very tiny stack to play with FSO and Qt Quick
Dec 07 18:06:43 <Ainulindale> mrmoku: With a nice heavy pair... of coffee pots!
Dec 07 18:06:48 <morphis> with not much stuff in the stack
Dec 07 18:06:54 <mrmoku> and some beer in between :)
Dec 07 18:06:57 <Ainulindale> morphis: What's "not much stuff" ?
Dec 07 18:07:04 <Ainulindale> Because if in the end you implement all the features
Dec 07 18:07:08 <Ainulindale> I'd say there'll be more stuff
Dec 07 18:07:09 <Slyon> mrmoku, you did it in modem_option_gtm601 while overwriting +COPS
Dec 07 18:07:11 <morphis> complete X11 with a lot of daemons and applications
Dec 07 18:07:20 <mrmoku> Slyon: yeah, but my memory sucks a lot :P
Dec 07 18:07:27 <Ainulindale> morphis: Well then isn't it the goal of the distro and not the stack?
Dec 07 18:07:36 <GNUtoo> Ainulindale, C is a nice high level programming language
Dec 07 18:07:51 <Ainulindale> What prevented you from using the current stack although stirpped down to the bare needed daemons?
Dec 07 18:08:32 <Ainulindale> Please note that I'm not saying it's a bad idea or criticizing there
Dec 07 18:08:40 <Ainulindale> Just trying to have an understanding of the reason
Dec 07 18:09:04 <Ainulindale> Because I witnessed so many "me not like me do yet another thingy" events in this community...
Dec 07 18:10:06 <mrmoku> Slyon: match = tere.match( response, 0, out mi );
Dec 07 18:10:22 <mrmoku> probably te = Terminal Equipment
Dec 07 18:10:43 <Slyon> mrmoku,  so tere = response from modem
Dec 07 18:10:45 <morphis> Ainulindale: first it's not another distro
Dec 07 18:10:51 <morphis> Ainulindale: it's SHR with another UI
Dec 07 18:11:07 <morphis> Ainulindale: mickeyl and I was impressed by the power you have with Qt Quick
Dec 07 18:11:27 <mrmoku> Slyon: yeah, regex that should match the modem's response
Dec 07 18:11:39 <Ainulindale> well do you really feel it's worth time and effort to build yet another UI morphis?
Dec 07 18:11:44 <morphis> Ainulindale: an we wanted a better replacement for zhone2
Dec 07 18:11:56 <morphis> Ainulindale: yes and no
Dec 07 18:12:12 <morphis> Ainulindale: you are right it's much time we need to get it working
Dec 07 18:12:17 <Slyon> mrmoku, that makes it easy, as AT+CHUP shouldn't give any response
Dec 07 18:13:00 <morphis> Ainulindale: but in detail you are really was with Qt Quick to implement new applications and features
Dec 07 18:13:28 <Ainulindale> morphis: I didn't understand this last sentence
Dec 07 18:13:52 <morphis> s/need/needed/
Dec 07 18:14:12 <mrmoku> Slyon: hehe, yeah
Dec 07 18:14:36 <Ainulindale> morphis: I didn't understand the last sentence, not the penultimate :-)
Dec 07 18:14:51 <morphis> Ainulindale: let's not continue this discussion right now as I run out of time
Dec 07 18:15:14 <morphis> Ainulindale: but in detail you are really fast with Qt Quick to implement new applications and features
Dec 07 18:15:23 <morphis> thats the correct sentence
Dec 07 18:15:29 <morphis> sorry for that
Dec 07 18:15:33 <Ainulindale> no problem
Dec 07 18:15:46 <morphis> Ainulindale: don't give the Aurora project too much importance
Dec 07 18:15:54 <morphis> the focus of the community is still at the SHR UI
Dec 07 18:16:00 <morphis> and thats ok and good
Dec 07 18:16:00 <JaMa> antrik: ok, then we both misunderstood each other a bit..
Dec 07 18:16:07 <Ainulindale> morphis: well
Dec 07 18:16:13 <Ainulindale> morphis: the SHR ui was crap when I stopped working on SHR
Dec 07 18:16:19 <Ainulindale> morphis: so I don't care about that :-)
Dec 07 18:16:31 <Ainulindale> I'm just trying to have a good vision of what's done and what'll be interesting
Dec 07 18:16:42 <morphis> ok
Dec 07 18:16:53 <morphis> then we should talk again when I have more time
Dec 07 18:16:56 <angelox|laptop> morphis: please, when you have time, check the about app i did create :D
Dec 07 18:17:10 <morphis> angelox|laptop: which one?
Dec 07 18:17:27 <angelox|laptop> in settings-rework app-about my three last commits
Dec 07 18:17:36 <morphis> angelox|laptop: ok
Dec 07 18:17:44 <angelox|laptop> there's an inma in aurora's screenshots page
Dec 07 18:17:47 <JaMa> antrik: and I was serious.. there was pyphonelog a while back, now there is ffphonelog and if someone brings something better and more shiny and nobody will care about ffphonelog then we would be able to drop it from feed, but as long as it's important part of SHR then people still care about it and it will be fixed whatever cost :)
Dec 07 18:17:49 <angelox|laptop> s/inma/image/
Dec 07 18:17:51 <apt> angelox|laptop meant: there's an image in aurora's screenshots page
Dec 07 18:18:38 <mrmoku> JaMa: there is started phonelog integrated in libphone-ui-shr... would just have to finish it :P
Dec 07 18:18:46 <morphis> Ainulindale: so you are back to the project now?
Dec 07 18:18:57 <Ainulindale> Certainly not
Dec 07 18:19:14 <Ainulindale> I don't have neither time or frame of mind for it :-)
Dec 07 18:19:18 <morphis> ok
Dec 07 18:19:19 <Ainulindale> Do unit tests, do QA
Dec 07 18:19:23 <Ainulindale> Then maybe I'll come back
Dec 07 18:19:26 <morphis> :)
Dec 07 18:19:28 <Ainulindale> Meanwhile, NO GO :-)
Dec 07 18:19:30 <JaMa> mrmoku: hehe, if pespin is right then maybe it will be easier to finish it then converting ffphonelog to new eflvala API :)
Dec 07 18:19:35 <mrmoku> Ainulindale: but you will certainly participate in the release part - whenever that is, right? :)
Dec 07 18:19:53 <Ainulindale> Well if we're still alive by then, sure
Dec 07 18:19:58 <JaMa> mrmoku: but Lukas is still sending patches for ff* so I belive he will fix it himself
Dec 07 18:20:02 <Ainulindale> :-p
Dec 07 18:20:06 <mrmoku> :P
Dec 07 18:20:19 <Ainulindale> mrmoku: but you know how it is
Dec 07 18:20:27 <Ainulindale> If there is no clear direction/leadership
Dec 07 18:20:30 <Ainulindale> with one firm goal
Dec 07 18:20:39 <Ainulindale> And if everybody does its thing by itself
Dec 07 18:20:48 <Ainulindale> It won't amount to much sadly because it won't have any coherence
Dec 07 18:20:53 <JaMa> mrmoku is respected and beloved leader! :)
Dec 07 18:21:13 <Ainulindale> (Not saying that it's bad that there are other initiatives there, only that it kills planification)
Dec 07 18:21:39 <JaMa> and he will also buy me nice BMW on our way to Essen I belive :)
Dec 07 18:21:50 * mrmoku never felt like being the leader... probably a wrong thing
Dec 07 18:22:13 <antrik> JaMa: I see. misunderstanding indeed :-)
Dec 07 18:22:21 <morphis> we have no one who is in the positon of a leader
Dec 07 18:22:34 <mrmoku> Ainulindale: that's all stuff we will discuss soon in a very nice location :)
Dec 07 18:22:36 <morphis> just a lot of people with a lot of thing to do :)
Dec 07 18:22:50 <mrmoku> Ainulindale: to get a plan
Dec 07 18:23:06 <Ainulindale> well
Dec 07 18:23:11 <Ainulindale> talking is one thing
Dec 07 18:23:14 <Ainulindale> enforcing it is another one
Dec 07 18:23:30 <Ainulindale> remember the heated discussion we had when I was still working? :-)
Dec 07 18:23:35 <Ainulindale> s/ssion/ssions/
Dec 07 18:23:36 <apt> Ainulindale meant: remember the heated discussions we had when I was still working? :-)
Dec 07 18:23:59 <mrmoku> the french - french discussions? ... yeah, how could I forget :P
Dec 07 18:24:02 <Ainulindale> sadly every project needs a leader even though it's not enjoyable nor rewarding
Dec 07 18:24:19 <Ainulindale> mrmoku: meh ! :-)
Dec 07 18:24:33 <Ainulindale> By the way I have no news about him (ptitjes)
Dec 07 18:24:48 <Ainulindale> He moved in the south of france a while back that's all I know
Dec 07 18:25:12 <mrmoku> I think he showed some signs of activity somewhere... not in here though
Dec 07 18:25:16 <Ainulindale> vala?
Dec 07 18:25:22 <mrmoku> libgee I think
Dec 07 18:25:39 <Ainulindale> Well I hope he'll stop hopping from project to project one day :-)
Dec 07 18:25:51 <mrmoku> as long as he's happy :)
Dec 07 18:25:53 <Ainulindale> Yep
Dec 07 18:25:59 <Ainulindale> I wasn't at the time though
Dec 07 18:26:06 <Ainulindale> It's hard to say no to someone with ideas
Dec 07 18:26:13 <Ainulindale> Especially in FLOSS communities
Dec 07 18:27:40 <GNUtoo> morphis, I've an issue with fsousaged on crespo:
Dec 07 18:27:42 <GNUtoo> 2011-10-18T02:56:24.611924Z [INFO]  fsousaged : received signal -11, shutting down...
Dec 07 18:27:46 <GNUtoo> continuously
Dec 07 18:27:47 <GNUtoo> hmmm
Dec 07 18:27:50 <Ainulindale> mrmoku: and by the way if there's no leader I think that by now you're the eldest or rather more ancient guy on the team :-)
Dec 07 18:28:00 <Ainulindale> mrmoku: so draw your own conclusions from that
Dec 07 18:28:28 <antrik> Ainulindale: well, you never have to say "no" to someone with ideas... just say "*show* us it can work" -- the effect will be the same in most cases; but in a few rare ones the person might indeed come up with something great :-)
Dec 07 18:28:53 <Ainulindale> well no
Dec 07 18:28:55 <Ainulindale> that's not a problem
Dec 07 18:28:57 <GNUtoo> maybe I should try a new iimage?
Dec 07 18:29:04 <Ainulindale> s/a /the /
Dec 07 18:29:04 <apt> Ainulindale meant: that's not the problem
Dec 07 18:29:26 <Ainulindale> The problem is when someone wants to redo everything whereas you talked a lot about the stuff, agreed on a compromise and set things in motion
Dec 07 18:29:38 <Ainulindale> And then you have each and every developer doing his own thing
Dec 07 18:29:40 <Ainulindale> And no common thing
Dec 07 18:29:47 <Ainulindale> Hence no coherence, no planning, no deliverable
Dec 07 18:29:54 <Ainulindale> => no usable phone :-)
Dec 07 18:30:06 <angelox|laptop> morphis: and please tell me what to work now (since settings-rework is finished)
Dec 07 18:30:42 <Ainulindale> mrmoku: but IMHO that's the thin line between a project and a "for free" project
Dec 07 18:30:50 <Ainulindale> You can't say no but you must say no 
Dec 07 18:31:30 <mrmoku> hmm
Dec 07 18:31:51 <mrmoku> Ainulindale: what do you mean by "for free" ?
Dec 07 18:32:58 <Ainulindale> well
Dec 07 18:33:02 <Ainulindale> you're not paid for SHR
Dec 07 18:33:09 <Ainulindale> you're doing that because you want to enjoy yourself and build something
Dec 07 18:33:20 <Ainulindale> so it's hard to be assigned to tasks you don't like
Dec 07 18:33:26 <Ainulindale> (such as QA, unit testing)
Dec 07 18:33:30 <Ainulindale> even though it's necessary
Dec 07 18:33:33 <mrmoku> ahh... difference between some comercial project and one like this one with volunteers
Dec 07 18:33:37 <mrmoku> yeah
Dec 07 18:33:38 <Ainulindale> yep
Dec 07 18:33:52 <antrik> Ainulindale: I don't think working on a compromise solution is viable in a volunteer project... people will only be motivated to work on something they are totally convinced of. so it needs a person with both a strong vision and the ability to bring it forward; so others will also get convinced, and join in rather than clamouring for compromises...
Dec 07 18:33:54 <mrmoku> indeed yeah
Dec 07 18:33:55 <Ainulindale> In my case, I didn't like posting in ML and blogs and such and forced myself to
Dec 07 18:33:58 <Ainulindale> And it was annoying
Dec 07 18:34:14 <Ainulindale> antrik: well you rephrased what I just said :-)
Dec 07 18:34:23 <pespin> hmm that remembers me I haven't posted in the shr blog since august lol
Dec 07 18:34:26 <Ainulindale> antrik: but that's why I created the core team 
Dec 07 18:34:41 <Ainulindale> The core team having the power to talk about stuff, decide, and impose the choice
Dec 07 18:35:00 <Ainulindale> Because in the end that's what necessary
Dec 07 18:35:32 <Ainulindale> A group of able and experienced people making choices with one of them being the guy taking the blows
Dec 07 18:35:41 <Ainulindale> (not the blowjobs, just plain actual blows)
Dec 07 18:35:52 <Ainulindale> As in every project in fact
Dec 07 18:36:04 <Ainulindale> (but again, that's only my humble theory)
Dec 07 18:36:48 <antrik> I don't think a core team works at all in a distributed project. only when people work together in one location, they can actually develop a vision together. otherwise, the only chance is for having a *single* person with a coherent vision
Dec 07 18:37:38 <Ainulindale> antrik: the core team is there to have heated discussion to come up with a consensual compromise
Dec 07 18:37:41 <Ainulindale> then the leader imposes
Dec 07 18:37:52 <Ainulindale> At least that's what I did when I was the (self-attributed) leader
Dec 07 18:38:07 <Ainulindale> And it (almost) worked
Dec 07 18:38:28 <Ainulindale> But my solution is only my solution, I don't pretend it to be the best
Dec 07 18:40:02 <Ainulindale> IMHO (again) if you lack this one decision step in such a project, the final architecture of the software will be as a shaked spaghetti plate
Dec 07 18:40:10 <Ainulindale> A huge mess
Dec 07 18:40:23 <Ainulindale> (compared to parallel spaghetti that is :-p)
Dec 07 18:40:52 <mrmoku> you're putting the spaghetti in parallel before eating them? ;)
Dec 07 18:42:04 <Ainulindale> Obviously yeah I'm insane
Dec 07 18:42:10 <Ainulindale> (No: I don't eat spaghetti)
Dec 07 18:42:16 <mrmoku> :P
Dec 07 18:42:19 <mrmoku> I have too
Dec 07 18:42:21 <mrmoku> often
Dec 07 18:42:35 <GNUtoo> /sbin/spa-getty ?
Dec 07 18:42:41 <Ainulindale> But I'm too fond of logical architectures well thought through and through
Dec 07 18:43:12 <antrik> heated discussions are possible without a core team ;-)
Dec 07 18:43:29 <Ainulindale> Yeah but then N > S
Dec 07 18:43:39 <Ainulindale> and you want to work with people who'll be motivated enough to do the dirty work
Dec 07 18:43:53 <Ainulindale> in order to ensure that in the end the work gets done and that for discussions S > N
Dec 07 18:44:07 <Ainulindale> Been there done that :-)
Dec 07 18:44:37 <Ainulindale> Because in the end even though you may deliver something not perfect
Dec 07 18:44:40 <Ainulindale> You'll deliver something
Dec 07 18:44:52 <Ainulindale> And if it needs modifications, it's never too late anyway (after the release ! :-p)
Dec 07 18:45:57 <antrik> well, Linux does well enough without a core team... sure, there is always noise in the discussions; but that is just something you have to get immune to
Dec 07 18:46:23 <GNUtoo> there are maintainers tough
Dec 07 18:47:46 <Ainulindale> antrik: there is a leader, there is a kind of "referee"
Dec 07 18:47:49 <mrmoku> indeed many subsystems all with maintainer(s) and there own mailing list for the heated discussions
Dec 07 18:47:59 <Ainulindale> antrik: and you're talking kernel which is far more  difficult than a mere UI
Dec 07 18:48:16 <Ainulindale> plus what the other guys said
Dec 07 18:48:19 <Ainulindale> :-)
Dec 07 18:48:50 <Ainulindale> antrik: again, not saying I have THE solution there, just trying to explain what I think is difficult in this kind of project
Dec 07 18:49:16 <antrik> mrmoku: most of the subsystems in turn have a clear leader and no core team
Dec 07 18:49:44 <Ainulindale> antrik: yeah but in this case it's almost the leader's job
Dec 07 18:50:01 <Ainulindale> antrik: and having leaders might be problematic (cf. Theo de Raadt)
Dec 07 18:50:11 <GNUtoo> lol
Dec 07 18:50:13 <Ainulindale> antrik: the core team is also there to be a buffer in order to prevent egomaniacs
Dec 07 18:50:36 <Ainulindale> Ask to mrmoku how long I talked with him about my problem with developers in SHR and if I was alone in thinking that
Dec 07 18:51:35 <Ainulindale> It feels more democratic that way, some kind of collective intelligence
Dec 07 18:51:54 <Ainulindale> And it forces members to understand they have some kind of responsibility
Dec 07 18:54:55 <nschle85> Ainulindale: what was your problem with developers in shr ?
Dec 07 18:56:11 <CIA-82> SHR: 03lukasmaerdian 07meta-smartphone * r114bfca0a325 10/meta-fso/recipes-freesmartphone/serial-utils/pty-forward.bb: meta-fso: add non-native pty-forward version
Dec 07 18:58:26 <antrik> Ainulindale: I don't really believe in democracy in managing free software projects. it causes endless infighting, and prevents true innovation
Dec 07 18:58:53 <Ainulindale> antrik: well it wasn't democracy per se
Dec 07 18:59:01 <Ainulindale> kind of an oligarchy
Dec 07 18:59:08 <Ainulindale> but with cooptation
Dec 07 18:59:14 <Ainulindale> anyways I have to eat, be back in a while
Dec 07 18:59:18 <antrik> unlike for state governments, we don't *need* democracy. if people don't like the leader in a project, they can just choose to work on another one.
Dec 07 18:59:25 <GNUtoo> again some strlen on NULL strings
Dec 07 18:59:34 <nschle85> antrik: or fork :-)
Dec 07 18:59:55 <GNUtoo> http://www.pastie.org/private/zzl9yydxhht3m9azumeeq
Dec 07 19:00:14 <antrik> nschle85: right. that's one way of working on another project :-)
Dec 07 19:00:28 <antrik> (usually preferable to starting from scratch)
Dec 07 19:01:07 <nschle85> see Hudson, LibreOffice, XFRee ....
Dec 07 19:03:40 <Ainulindale> it's not always a good thing
Dec 07 19:04:48 <GNUtoo> xorg was a good thing
Dec 07 19:05:10 <nschle85> GNUtoo: agree but forking often reduces manpower
Dec 07 19:10:13 <antrik> nschle85: not really. usually the branch with the better leadership (whichever one it is) quickly comes out on top, and the other dies off.
Dec 07 19:10:28 <GNUtoo> depends
Dec 07 19:10:45 <GNUtoo> in xorg it took the project ahread
Dec 07 19:10:55 <antrik> many projects actually gained *more* developers by forking and thus getting rid of poor leadership
Dec 07 19:11:05 <GNUtoo> there was the split(monolithic xorg -> modular xorg)
Dec 07 19:11:06 <GNUtoo> etc...
Dec 07 20:21:46 <GNUtoo> morphis, I've found why it fails but I've no idea how to fix
Dec 07 20:21:48 <GNUtoo> in:
Dec 07 20:22:04 <GNUtoo> fsousaged/src/plugins/dbus_service/plugin.vala:
Dec 07 20:22:30 <GNUtoo> this.system_action( action );
Dec 07 20:22:34 <GNUtoo> action can be null
Dec 07 20:22:44 <GNUtoo> and system_action is a signal
Dec 07 20:22:53 <GNUtoo> so that creates the trace I shown before
Dec 07 20:22:56 <GNUtoo> hi mickeyl 
Dec 07 20:23:12 <GNUtoo> I guess that's related to the vala upgrade
Dec 07 20:25:47 <morphis> GNUtoo: I know this error
Dec 07 20:26:09 <GNUtoo> ok
Dec 07 20:26:26 <GNUtoo> can you fix it? or is it me that didn't rebuild or something like that?
Dec 07 20:26:33 <morphis> you need vala-0.14.7-... from here http://downloads.freesmartphone.org/vala-0.14.1.7-3673f.tar.bz2
Dec 07 20:26:45 <morphis> it's already included in OE
Dec 07 20:26:51 <GNUtoo> ok so I'll rebuild
Dec 07 20:26:57 <morphis> check if you building with this vala version
Dec 07 20:27:09 <morphis> if not rebuild vala and then all fso stuff
Dec 07 20:27:15 <GNUtoo> I think I built with an old vala
Dec 07 20:27:25 <morphis> yes
Dec 07 20:28:06 <GNUtoo> thanks a lot
Dec 07 20:28:12 <morphis> no problem :)
Dec 07 20:30:17 <morphis> thats my job as FSO developer :)
Dec 07 20:45:08 <mrmoku> morphis: a FSO developer is what I need now :P
Dec 07 20:45:26 <mrmoku> morphis: do fso daemons need /dev/pts ?
**** BEGIN LOGGING AT Wed Dec 07 23:52:25 2011
Dec 07 23:56:42 <mickeyl> mrmoku: IIRC only those which open a pty, i.e. fsogsmd for some configurations
Dec 08 01:00:57 <angelox|laptop> gnight people
**** ENDING LOGGING AT Thu Dec 08 02:59:57 2011