IRC log for #openmoko-cdevel on 20111207

01:22.44*** join/#openmoko-cdevel playya__ (~playya@unaffiliated/playya)
01:42.24*** join/#openmoko-cdevel wolfspraul (~wolfsprau@mimi.q-ag.de)
01:52.11*** join/#openmoko-cdevel DieMumiee (~DieMumiee@p3E9C357F.dip.t-dialin.net)
02:27.23*** join/#openmoko-cdevel TAsn (~tom@enlightenment/developer/TAsn)
02:28.32*** join/#openmoko-cdevel wolfspraul (~wolfsprau@mimi.q-ag.de)
02:45.58*** join/#openmoko-cdevel wolfspraul (~wolfsprau@mimi.q-ag.de)
02:46.32*** join/#openmoko-cdevel wolfspra1l (~wolfsprau@222.129.242.202)
03:14.46*** join/#openmoko-cdevel plotr (~name@dnm.174.114.126.92.dsl.krasnet.ru)
03:40.25pabs3wonders whats the license of that Miso.ttf
04:47.13*** join/#openmoko-cdevel erwt (~erwt@114.143.160.125)
05:26.37*** join/#openmoko-cdevel wolfspraul (~wolfsprau@222.129.242.202)
05:33.22*** join/#openmoko-cdevel DocScrutinizer (~halley@openmoko/engineers/joerg)
05:45.48*** join/#openmoko-cdevel snkt (~snkt@114.143.160.125)
06:17.42*** join/#openmoko-cdevel pwerken (~pwerken@square.phys.uu.nl)
06:32.00mrmokumoin
06:35.02*** join/#openmoko-cdevel HeinervdmWork (~zimmerman@hsaggate.physik.uni-bonn.de)
06:48.58*** join/#openmoko-cdevel JaMa (~martin@94.230.152.246)
07:11.12*** join/#openmoko-cdevel Mirv (~tajyrink@ubuntu/member/mirv)
07:35.13*** join/#openmoko-cdevel radekp (~radek@82.113.39.213)
07:44.14JaMamoin
07:45.36*** join/#openmoko-cdevel erwt (~erwt@114.143.160.125)
07:50.56*** join/#openmoko-cdevel erwt (~erwt@114.143.160.125)
07:52.50*** join/#openmoko-cdevel mrmoku` (~mrmoku@ppp-188-174-98-230.dynamic.mnet-online.de)
07:54.43*** join/#openmoko-cdevel mrmoku (~mrmoku@ppp-188-174-98-230.dynamic.mnet-online.de)
07:55.49*** join/#openmoko-cdevel pwerken (~pwerken@square.phys.uu.nl)
08:11.01*** join/#openmoko-cdevel ThibG (~ThibG@81-64-18-234.rev.numericable.fr)
08:16.03*** join/#openmoko-cdevel plotr (~name@178.185.50.82)
08:26.40*** join/#openmoko-cdevel pwerken (~pwerken@square.phys.uu.nl)
08:47.47*** join/#openmoko-cdevel keenbug (~daniel@p4FE393CF.dip.t-dialin.net)
08:49.27*** join/#openmoko-cdevel pwerken (~pwerken@square.phys.uu.nl)
09:02.01CIA-82SHR: 03Martin.Jansa 07shr-chroot * r286c19b84a52 10/ (5233 files in 326 dirs): system upgrade
09:07.09*** join/#openmoko-cdevel morphis (~morphis@dslb-088-071-179-155.pools.arcor-ip.net)
09:07.47morphisheyho
09:07.55morphismickeyl: ping
09:07.58CIA-82SHR: 03Martin.Jansa 07shr-chroot * r9c39ed37ceb0 10/OE/ (13 files): sync scripts and bashrc from 64bit
09:09.05JaMaheyho
09:11.22*** join/#openmoko-cdevel ao2 (~ao2@2001:1418:117::1)
09:18.33*** join/#openmoko-cdevel pwerken (~pwerken@square.phys.uu.nl)
09:25.14mrmokuJaMa: I installed latest, closed staging and will use it as daily now
09:25.29mrmokuso far it looks good
09:25.53mrmokuapart from the keyboard not popping up automatically anymore
09:26.10mrmokudunno if that changed in elementary and has to be requested explicitely now
09:26.27mrmokuthat is kind of bad for the first start wizard... you can't pop it up manually there :P
09:29.31JaMan900 or gta?
09:29.56mrmokugta02
09:30.49mrmokuI installed 003 on n900 too
09:30.54mrmokudid not boot on first try though
09:30.58mrmokuhave to look into it
09:31.05mrmokuprobably just the SD not mounted correctly
09:31.14JaMaok, 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 :)
09:31.59*** join/#openmoko-cdevel SabotageAndi (~SabotageA@h081217018227.dyn.cm.kabsi.at)
09:32.36mrmokuindeed SD was not in properly
09:32.39mrmokunow it boots
09:35.18*** join/#openmoko-cdevel GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net)
09:36.44*** join/#openmoko-cdevel pespin (~pespin@245.pool85-50-65.dynamic.orange.es)
09:43.28*** join/#openmoko-cdevel pespin (~pespin@245.pool85-50-65.dynamic.orange.es)
09:46.26*** join/#openmoko-cdevel lamikr (lamikr@nat/nokia/x-kglpkemblkrhqgxa)
09:47.25mrmokuand has the backlight issue
09:49.16pespinJaMa, hi! I pushed your emtooth2 stuff, rev 164
09:50.35mrmokuJaMa: no usb network either... that makes it difficult :)
09:50.55*** join/#openmoko-cdevel otypoks (~otypoks@host-5db0d228.sileman.net.pl)
09:53.02mrmokubbl
10:06.06*** join/#openmoko-cdevel Martix (~martix@134.89.broadband12.iol.cz)
10:17.06JaMamrmoku: I had to switch from g_nokia to g_ether to get usb networking working..
10:25.25*** join/#openmoko-cdevel dos1 (~dos@unaffiliated/dos1)
10:25.37CIA-82SHR: 03Martin.Jansa 07shr-chroot * re6c447750dac 10/var/ (7 files in 3 dirs): bitbake upgrade
10:28.01CIA-82SHR: 03Martin.Jansa 07shr-chroot * r3a71034f33cc 10/ (36 files in 12 dirs): bitbake upgrade
10:28.54dos1http://build.shr-project.org/tests/site/
10:29.24dos1i think only shr-core-staging support is left (selecting other image than latest)
10:30.09JaMados1: latest shr-core-staging not always have images
10:30.20morphisdos1: the site looks really great!
10:30.45dos1JaMa: yup, so i have to suport that somehow
10:31.13dos1morphis: :)
10:31.26morphisHTML5 is a great thing :)
10:34.39morphisJaMa: btw. we should add the image + kernel filename to the list add http://shr-project.org/trac/wiki/StagingTests
10:34.51morphisJaMa: as the Aurora, SHR Full, SHR Lite can be used
10:34.56morphis+ the different kernels
10:36.51JaMawe can consider Lite and Full the same functionality wise imho.. but I'll add shr/aurora as special type for 004
10:38.35GarthPShi huys. nice work ! :)
10:38.39*** join/#openmoko-cdevel mickey_office (~mickey@business-092-079-168-007.static.arcor-ip.net)
10:40.15GarthPScan 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 :
10:40.18GarthPSERROR: libmad was skipped: because it may require a commercial license to ship in a product (listed in COMMERCIAL_LICENSE)
10:40.31GarthPSwhere do I set COMMERCIAL_LICENSE and to what ?
10:41.49JaMato empty in local.conf
10:42.06JaMathere is an example i belive in latest local.conf from SHR
10:42.58JaMaGarthPS: 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
10:43.15morphisJaMa: ok
10:47.15*** join/#openmoko-cdevel otypoks_ (~otypoks@host-5db0d228.sileman.net.pl)
10:48.12morphisJaMa: and how do you build the several testing images?
10:49.49JaMathe process is still the same only rsync after build is different
10:50.42JaMaalias bbaif="bb -k shr-lite-image shr-image aurora-image | tee -a log.\${MACHINE}; bb -k task-shr-feed | tee -a log.\${MACHINE}; reindex"
10:50.50CIA-82SHR: 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
10:50.54CIA-82SHR: 03morphis 07meta-smartphone * r0418bb9eff98 10/meta-aurora/recipes-aurora/aurora/aurora-base.inc: meta-aurora: aurora-base: bump SRCREV
10:51.05CIA-82SHR: 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
10:51.05JaMaand for cycle to call it for each machine
10:51.11morphisJaMa: ok
11:05.14*** join/#openmoko-cdevel lamikr (lamikr@nat/nokia/x-zjlntjrgoeqcbzll)
11:05.16*** join/#openmoko-cdevel GNUtoo (~gnutoo@host42-159-dynamic.51-79-r.retail.telecomitalia.it)
11:08.43GNUtooI think I have the fix for mplayer
11:09.07GNUtooI'll push it
11:10.20morphisGNUtoo: heyho
11:10.26morphisGNUtoo: I have ALSA with dmix working
11:10.35morphiswith the android kernel
11:10.40morphisand without broonie modifications
11:10.56morphiss/broonie/broonie's/
11:11.37GNUtoomorphis, ok nice
11:11.51morphisGNUtoo: you just need to disable CONFIG_S5P_INTERNAL_DMA
11:11.58GNUtooah ok
11:12.13GNUtoowhat about the controls ?
11:12.16morphisI played a little bit with it playing multiple audio files at the same time
11:12.29morphiswe can use the Android set of controls
11:12.32GNUtoook
11:12.35morphiswould be easier
11:12.44morphisotherwise I got it working with broonie's kernel too
11:12.51GNUtooandroid set of controls are somehow buggy
11:12.58morphisreally?
11:13.09GNUtooyes I know why there is bad sound sometimes
11:13.19GNUtooI suspect that some routing paths are forbidden
11:13.35GNUtooin the sense that if you go there it put the CODEC in a bad state
11:13.42GNUtooand after you need to reboot
11:14.00GNUtooI've mplayer2 working on om-gta02 btw
11:14.04morphisgreat
11:14.20morphisso what do you think, should we use android controls or the real ones from broonie's kernel?
11:14.31GNUtoohmmm
11:14.36GNUtoothe android ones may be buggy
11:14.43morphisI don't have any clue how to figure out which controls we need to set for getting call audio working
11:14.43GNUtoothe bronie ones may break your device
11:14.48morphisyes
11:14.56*** join/#openmoko-cdevel erwt (~erwt@114.143.160.125)
11:14.56morphisso I think we should stay with android ones
11:15.00GNUtoook
11:15.04morphisbut we need to fix the alsamixer-thing
11:15.10GNUtooyes
11:15.23GNUtoobut maybe that can be worked arround
11:15.23morphisso we don't need to set the controls to their correct values everytime someone wants to play audio
11:15.25GNUtoowith amixer
11:15.32morphishow?
11:15.42GNUtoosimply by setting the value directly
11:16.01GNUtooand not by cycling trough the values
11:16.03GNUtoohowever
11:16.22GNUtooit doesn't fix the fact that it removes the settings at .close
11:17.06morphisyes
11:17.19morphisand for this we need to find a work-around
11:17.59GNUtoono
11:18.04GNUtoowe need to fix it in the code
11:18.19GNUtooit would be easier
11:19.21morphisok, do you know where?
11:19.37morphisbtw. whats the state for wifi?
11:20.13morphisand about your not-working telephony on crespo device: it works fine here with ${AUTOREV}
11:20.42JaMaGNUtoo: please be more carefull with extra newlines on wiki, ie: http://www.shr-project.org/trac/wiki/StagingTests?action=diff&version=19
11:21.00morphisand I am currently taking a look at your code for setting up the GPRS conneciton with android
11:21.04GNUtoomorphis, ok
11:21.44GNUtooJaMa, ok btw music fails and I've a fix
11:22.04JaMagood
11:22.36GNUtoothe fix is a better mplayer.conf
11:22.44GNUtoowith alsa and tremor instead
11:22.47GNUtoobut only for om-gta02
11:23.15morphisGNUtoo: do you have some log output for me about the PDP part in the ril?
11:23.27GNUtoomorphis, yes let me look
11:24.22morphisand you need to listen for IPC_GPRS_IP_CONFIGURATION unsolicited response message
11:25.37GNUtoook
11:25.43GNUtooI did that instead:
11:25.50GNUtoonetcfg dhcp rmnet0
11:25.53GNUtooor something like that
11:25.59morphisno
11:26.03morphisthat doesn't work
11:26.10GNUtooahhh ok
11:26.12morphisyou need to use the IP settings which comes with the response
11:26.16GNUtoook
11:26.30GNUtooit worked on qualcomm devices tough
11:26.33GNUtoothat's why I did it
11:26.36morphishm
11:26.42morphisfor me it didn't worked
11:27.55GNUtoook
11:30.17GarthPSJaMa: thx!
11:30.27JaMaGarthPS: ?
11:30.28GarthPSdon't know what is commercial licence..
11:30.32JaMaah
11:31.37GarthPSJaMa: and byt the way  what is this for ? "export BBFETCH2=True"
11:31.49GNUtoomorphis, http://www.pastie.org/private/nmvqtauyle3s19wgvbdd7w
11:32.57morphisGNUtoo: you get a IPC_GPRS_IP_CONFIGURATION so PDP context is up
11:32.59GNUtooGarthPS, I guess COMMERCIAL_LICENSE is for not putting patent-infridging code in the product(like for instance mp3 encoder/decoder)
11:33.05GNUtoook thanks
11:33.12GNUtooI just need to listen to the IP then
11:33.32GNUtooJaMa, am I right about COMMERCIAL_LICENSE?
11:33.48GarthPSyeah I was thinking about that ..
11:34.26morphisGNUtoo: yes and set the IP + dns servers according to the content of the IP_CONFIGURATION_MESSAGE like I did in FSO
11:34.42*** join/#openmoko-cdevel otypoks_ (~otypoks@host-5db0d228.sileman.net.pl)
11:34.49GNUtooyes I'll do that
11:34.59GNUtooaltough I'll commit the gta02 stuff before
11:35.29morphisok
11:35.41JaMaGNUtoo: yes something like that
11:36.04JaMaGarthPS: to select fetch2 instead of older fetch1 implementation (which is not supported by oe-core)
11:37.03GarthPSok thx
11:44.07mrmokudos1: yo, you rock :-)
11:47.52*** join/#openmoko-cdevel wolfspraul (~wolfsprau@222.130.123.99)
11:49.18morphisGNUtoo: <morphis> ok, do you know where?
11:50.55GNUtoono I don't, I'll look after mplayer + data in replicant
11:51.43CIA-82SHR: 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
11:51.44CIA-82SHR: 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
11:53.42morphisGNUtoo: ok
11:54.00*** join/#openmoko-cdevel dos1 (~dos@unaffiliated/dos1)
11:54.31dos1pabs3: http://build.shr-project.org/tests/site/MISO-info.txt
11:59.39CIA-82SHR: 03Martin.Jansa 07meta-smartphone * r2d8026e5091b 10/meta-shr/recipes-shr/3rdparty/emtooth2_svn.bb: emtooth2: bump SRCREV again and drop applied patch
12:04.37pabs3dos1: I see, not something that could ever go into Debian then
12:10.10mrmokumickey_office: any suggestion what we could do about our 'fsodeviced comes too late to load firmware' problem?
12:11.11morphismrmoku: what means fsodeviced comes too late?
12:11.38mrmokumorphis: modules being loaded and requesting firmware before fsodeviced is around
12:12.20mrmokusure we can try to move fsodeviced to start a tad earlier or module loading to come a bit later
12:12.34mrmokudunno if that is the correct solution generally speaking
12:12.57morphishm
12:13.03morphisabout whic modules we're talking here?
12:13.23mrmokuon n900 it is etk8...
12:13.28JaMaor let modules and fsodeviced start in paralel :)
12:14.54morphishm
12:15.04morphisetk8 is required for network?
12:16.09mrmokuI don't think so
12:16.39mrmokumorphis: I'm more concerned in general
12:16.54mrmokuwhat if fsodeviced needs some module for some plugin?
12:17.03mrmokuthen we would have to load modules first
12:17.07mrmokuand then fsodeviced
12:17.16morphisyes but if the module requires a firmware then ..
12:17.20morphiswe have a problem
12:17.22morphisyou are right
12:17.26mrmokuthat's the point, yeah
12:17.35morphismaybe we need something like a deffered plugin loading
12:17.58mrmokuor exctract the firmware loader into a small thing on it's own
12:18.02morphisyes
12:18.06morphisbut for the moment
12:18.15morphiswho requires the etk8 module?
12:18.20pabs3isn't udev the thing for loading firmware?
12:18.22morphisso we can decide what we can do for the moment
12:18.27morphispabs3: not in SHR
12:18.32morphiswe're not using udev anymore
12:18.48pabs3huh, why is that?
12:19.51morphisas we're using devtmpfs + fsodeviced for that
12:19.58morphisfsodeviced has a firmware loader
12:21.29mrmoku2011-12-04T12:42:03.247772Z [ERROR] KernelCpuResource <CPU>: Could not register CPU with ousaged: Error calling StartServiceByName for org.freesmartphone.ousaged: GDBus.Error:org
12:21.33mrmoku.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/libexec/dbus-daemon-launch-helper: Success; trying to enable the resource unconditionally
12:21.55mrmokuroot@nokia900:~# ls -l /usr/libexec/dbus-daemon-launch-helper
12:21.55mrmoku-rwsr-xr--    1 root     root        185056 Nov 21 07:02 /usr/libexec/dbus-daemon-launch-helper
12:21.57mrmokudamn
12:22.00morphis:)
12:22.25mrmokuJaMa: that explains the backlight problem I think
12:24.50JaMamrmoku: not for me as I was extracting image with --numeric-owner
12:25.10JaMa-rwsr-xr-- 1 root messagebus 185056 Nov 20 12:42 /usr/libexec/dbus-daemon-launch-helper
12:26.06mrmokuJaMa: I have that --numeric-owner in my install script too
12:26.21JaMawhich image did you took?
12:26.22JaMa003?
12:26.26mrmokuand fixing the permissions and restarting fsodeviced makes the backlight work
12:26.29mrmokuyeah 0003
12:26.30mrmoku-0
12:27.32JaMahmm 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
12:27.40mrmokuJaMa: -rwsr-xr--  1 root root 185056 Nov 21 08:02 dbus-daemon-launch-helper
12:27.43mrmokuyeah :)
12:28.44JaMaand http://build.shr-project.org/shr-core-staging/003/images/om-gta02/shr-lite-20111204-om-gta02-testlab/files-in-image.txt is right
12:28.58JaMakillling 004 image build
12:29.09mickey_officemrmoku: can you recap the problem for me? missing context
12:29.17mickey_officeah, i guess i know
12:29.24mickey_officefsodevice not started @ module loading time?
12:29.31mrmokumickey_office: fsodeviced is needed when modules are loaded that request a firmware
12:29.33mickey_officeonly one solution thereĀ… start it earlier.
12:29.34mrmokuyeah, exactly
12:29.49mrmokuon the other hand fsodeviced might need a module for some plugin
12:30.02morphismickey_office: good you are here
12:30.02mrmokusome kind of hen-egg thingie
12:30.09mickey_officemrmoku: not much of a problem
12:30.27mickey_officewe can teach fsodeviced to rerun a detection phase when a new module is loaded
12:30.30mickey_officeit can detect that via kobject
12:31.21mrmokuoh, diego woke up... brb
12:32.53morphismickey_office: you have some time right now for the vala things?
12:33.37mrmokumickey_office: ok
12:36.02JaMamrmoku: I think I've found the problem with dbus owner in sstate (missing --numeric-owner there too)
12:36.11mrmokuJaMa: great
12:39.22mickey_officemorphis: yo
12:41.00mrmokurc0.d/K27fsodeviced  rc1.d/K27fsodeviced  rc2.d/S27fsodeviced  rc3.d/S27fsodeviced  rc4.d/S27fsodeviced  rc5.d/S27fsodeviced  rc6.d/K27fsodeviced
12:41.04mrmokurcS.d/S04modutils.sh
12:41.07radekpmrmoku: you can embed firmware to modules, if you dont have licensing problem with that
12:41.08mrmokurc0.d/K20dbus-1  rc1.d/K20dbus-1  rc2.d/S02dbus-1  rc3.d/S02dbus-1  rc5.d/S02dbus-1  rc6.d/K20dbus-1
12:41.34mrmokuradekp: hmm... I think we would have issues with that
12:42.32mrmokuwould be the most elegant solution though :)
12:42.38*** join/#openmoko-cdevel jonwil (~jonwil@27-33-137-199.static.tpgi.com.au)
12:43.33mrmokumickey_office: would it be feasible to make fsodeviced start without dbus? and detect when dbus gets started?
12:43.38morphismickey_office: so with which one do we want to start?
12:44.02radekpalso starting "udevd", then modprobe "module_which_needs_fw", kill udevd was working
12:44.14mrmoku:P
12:44.19mrmokuradekp: that I call a hack ;)
12:44.24radekptoo :)
12:44.38radekpbut i think you can write small program that just calls libudev
12:45.01radekpIIRC udev is written as library, you can use it just for FW loading
12:45.29radekphas the same problem on QtMoko
12:45.35mrmokuyeah, but before we do that we could extract fsodeviceds firmware loader
12:45.41mrmokuradekp: hmm... interesting
12:46.27radekpi am also not using normal udev anymore
12:46.28mrmokuradekp: we should find a solution then that works for you too
12:46.34mrmokuyeah, we neither
12:46.45mrmokuare you using fsodeviced?
12:46.49mickey_officemrmoku: i don't know offhand whether that would work, worth a try
12:47.13mrmokumickey_office: starting after dbus is a quite limiting factor in moving fsodeviced early :)
12:47.18radekpi have FSO just as optional dependency
12:47.42mickey_officemrmoku: i see. well, i have to think about that
12:47.46radekpi do images based on debian stable, which does not have FSO
12:47.50mrmokumickey_office: ok :)
12:47.52GNUtooJaMa, I tought that adding mplayer-common/om-gta02 marked it to machine-arch automatically
12:48.07GNUtooArchitecture: all
12:48.23GNUtoothat's what I have with opkg info mplayer-common on target
12:49.00JaMadid you bump PR or -force-reinstall it?
12:49.29JaManot sure if inherit all arch doesn't override mplayer-common/om-gta02 in SRC_URI..
12:51.19GNUtoook
12:51.47GNUtooI'll machine arch it for om-gta02 and retry then
12:51.58mickey_officemorphis: 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.
12:52.00radekpmrmoku: maybe you could load the module which needs firmware when FSO is started
12:52.19radekpmrmoku: and fso can then supply the fw
12:52.21JaMaGNUtoo: it's in meta-openmoko right?
12:52.35radekpmrmoku: instead of making FSO start sooner, you can load the module later :)
12:52.44mickey_officewell
12:52.56mickey_officegiven that FSO on some platforms perform quite critical things, starting fsodeviced at least soon is a good idea
12:53.01mickey_office(think battery chargingĀ….)
12:53.12GNUtooyes
12:56.49mickey_officethen again, i can offer you another alternative
12:56.56mickey_officewe create fsosystemd
12:57.03mrmoku:)
12:57.04mickey_officeand put all the non-dbus system service plugins in there
12:57.08mickey_officelike charging
12:57.10mickey_officefirmware loading
12:57.11mickey_officeand what not
12:57.19mrmokuinit too?
12:57.23mickey_officei think that would be a clean solution
12:57.27mickey_officeya, why not, it would belong there
12:57.51mrmokuhow much work is it?
12:57.58morphismickey_office: state of master branch regarding vala is ok, everything should work back again
12:58.15morphismickey_office: we had some problems with the changed behaviour of supplying structs as parameters
12:58.28morphiswhich does not lead to compilation error but to runtime errors
12:58.31morphisthat is fixed
12:58.38mickey_officewell, the init stuff is a more complex task, but we could start with the other things, that would be easy
12:58.53morphis0.14.1 does not include the fixes we need
12:59.18morphisI already talked to luca bruno about getting my fixes into 0.14.2 and he is reviewing my changes
12:59.20mickey_officemorphis: hmm, so you merged the 014-support to cornucopia-master?
12:59.33morphisafter the problems were gone, yes
12:59.38mickey_officehmm
12:59.39mickey_officeok
12:59.45morphismaster is usable now with 0.14.1.7-....
12:59.50mickey_officethat means i must fix / revert
12:59.55mickey_officethe things that i don't like
13:00.02morphiswhich is here http://downloads.freesmartphone.org/vala-0.14.1.7-3673f.tar.bz2
13:00.08morphisyes
13:00.51mickey_officehmm, ok
13:01.32morphisI pulled playya__ mdbus2 gbus porting patches in
13:01.36morphisafter some testing and fixes
13:02.51mickey_officemrmoku: 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
13:03.20morphismickey_office: but please fix the things you don't like
13:03.42radekpmrmoku: btw do you remember why SHR dropped udev?
13:03.45mickey_officemorphis: 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
13:04.01JaMaradekp: it was much slower then devtmpfs is
13:04.14mickey_officeradekp: because it's slow and cumbersome and eats kittens. and devtempfs is almost a full substitute for it
13:04.20JaMaradekp: see bootcharts http://build.shr-project.org/tests/jama/
13:04.44radekpi think the problem with udev is that it touches all the uevent files on startup
13:05.06radekpwhich is slow, but if this could be disabled, then it could be ok
13:06.19radekpIIRC 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
13:07.22radekpotherwise udevd should be quite lightweight - it's written in pure C, it has 120kb here
13:07.43JaMait's much better with systemd
13:07.58radekpif i run udevd from command line it's up instantly
13:08.40radekpit starts in 1ms
13:10.49*** join/#openmoko-cdevel dos1|N900 (~dos@unaffiliated/dos1)
13:11.05CIA-82SHR: 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
13:11.25dos1|N900JaMa, mrmoku: ping
13:11.42dos1|N900we'll need some option to be set in apache conf for our vhost
13:12.08dos1|N900IndexOptions +SuppressHTMLPreamble
13:12.28mrmokumickey_office: ok, maybe I take a look
13:12.40mrmokudos1|N900: pong
13:13.10dos1|N900i would set it in .htaccess, but its parsing is disabled
13:13.14mickey_officemrmoku: cool. it would help me if you just create the daemon and move the plugins from fsodeviced to fsosystemd
13:13.15mrmokudos1|N900: is that a option that can be set via .htaccess?
13:13.32mickey_officemrmoku: i'm still interested to work on the init system
13:13.35mrmokumickey_office: yeah... that should be inside my skills :P
13:13.37mickey_office:)
13:13.38dos1|N900mrmoku: ^^
13:13.48mrmokudos1|N900: ok
13:14.23mrmokudos1|N900: would we prefer turning on .htaccess parsing?
13:14.45mrmokuor just get that IndexOptions in the conf
13:14.47dos1|N900it's not critical, but you can see on your own what mess is in html code of my page
13:15.08dos1|N900mrmoku: turning on .htaccess would be much more flexible for us in the future :D
13:15.55mrmokuok
13:16.28mrmokuhas to do a longer daywork phone call first and will then see to get some bearstech contact
13:16.38dos1|N900ok, thx
13:17.02dos1|N900(.htaccess is already on its place, patiently waiting to be respected :))
13:17.08mrmoku:)
13:22.15GarthPSdoes 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
13:25.55morphismrmoku: there is already the fsoinitd which you can use as base for fsosystemd
13:26.13mrmokumorphis: yeah, will mix it alltogether :)
13:26.23morphisbut disable the init part :)
13:26.30mrmokusure :P
13:29.08mrmokudos1|N900: is enabled now
13:35.01mrmokuradekp: btw. regarding charging on gta04... you have twl4030_charger.allow_usb=1 in your cmdline?
13:48.52GNUtooGarthPS, please paste the full command
13:49.02GNUtoos/command/line
13:49.13GNUtoo(the @base_conditional
13:49.14GNUtoo)
13:50.11GarthPSGNUtoo: DEPENDS = "libfribidi libtool libgcrypt gst-plugins-bad virtual/libsdl qt4-x11-free dbus libxml2 gnutls tremor faad2 ffmpeg flac \
13:50.11GarthPS"
13:50.11GarthPS#           ${@base_conditional('ENTERPRISE_DISTRO', '1', '', 'libmad libid3tag liba52 mpeg2dec', d)}"
13:50.38GNUtooGarthPS, if entreprise distro is 1 then add '' as dependences, else add 'libmad etc....'
13:50.42GNUtoothat's what it does
13:50.56GNUtooand there is a comment before also
13:50.59GNUtooso remove the comment
13:51.08GarthPSSo for me right now vlc_1.1.11 is broken as it does not build if you don't build libmad before
13:51.11GNUtoobut it'll surely fail with lacking recipes
13:51.17GNUtooyes
13:51.24GNUtooGarthPS, what about mplayer?
13:52.25GarthPSGNUtoo: why it is commented  ? mplayer did not tried yet
13:52.49GNUtoobecause I guess that some recipes were not in core based oe at the time
13:53.16GNUtoosome of the dependencies like libmmad etc...
13:53.32GNUtooGarthPS, oe-core still lacks a lot of recipes
13:53.49GarthPSGNUtoo: well libmad is there now
13:53.53GNUtooand I really don't have the time to add them back
13:54.07GNUtooyes so try uncommenting that line and see what's still lacking
13:54.15GarthPSGNUtoo:  I will tell you if the comment can be removed
13:54.25GarthPStrying to build vlc right now
13:54.31GNUtooif so send a patch
13:54.40GNUtooor push if you have push access
13:56.00GarthPSGNUtoo: ok I will (don't have right access)
13:56.08GNUtoook
13:56.09GarthPSor write access :)
13:56.15GNUtoook
13:58.18JaMaGarthPS: please send it directly to OE-devel ML as written in README of meta-oe layer ;)
13:58.41radekpmrmoku: is that needed?
13:59.57JaMaGarthPS: also read this thread http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-September/034954.html
14:00.42mrmokuradekp: yup, with 3.x it is needed to enable charging
14:00.52mrmokudid not try the wall charger as I can't find it :P
14:01.04mrmokubut for charging via usb I need that
14:01.51radekpmrmoku: cool thanks, i'll try
14:01.56mrmokuyw
14:16.44dos1|N900mrmoku: great, thanks :)
14:16.52dos1|N900it works \o/
14:32.58*** join/#openmoko-cdevel anarsoul (~anarsoul@86.57.155.118)
14:38.19mrmokudos1|N900: good :)
14:46.56*** join/#openmoko-cdevel angelox|laptop (~Angelo@189-18-205-121.dsl.telesp.net.br)
14:47.54*** join/#openmoko-cdevel paulk (~paulk@lib33-1-82-233-88-171.fbx.proxad.net)
14:51.43*** join/#openmoko-cdevel dos1 (~dos@ajp246.neoplus.adsl.tpnet.pl)
14:51.46*** join/#openmoko-cdevel dos1 (~dos@unaffiliated/dos1)
15:15.38*** join/#openmoko-cdevel wolfspraul (~wolfsprau@222.130.123.99)
15:19.26angelox|laptopdos1: wow, fantastic working site :)
15:56.49dos1i've flashed shr-aurora on gta02
15:57.00dos1how to turn off the device correctly? xD
15:57.11angelox|laptopwopps we forgot that part :)
15:57.59angelox|laptopwhen i had my n900 i turned off using ssh :)
15:58.55mrmokudos1: just use the battery switch ;)
16:15.14Ainulindaleaurora ?
16:15.16Ainulindalewhat's that?
16:22.02mrmokuAinulindale: framebuffer, qt based feature phone flavour
16:22.19mrmokumainly invented by morphis and mickey_office to have a simple testbed for fso
16:24.59*** join/#openmoko-cdevel turran (~jl@227.pool85-50-76.dynamic.orange.es)
16:24.59*** join/#openmoko-cdevel turran (~jl@unaffiliated/turran)
16:27.08angelox|laptopwow, morphis was there and i did not see :)
16:27.22angelox|laptopmorphis: http://wiki.freesmartphone.org/index.php/Aurora/Screenshots
16:30.08mrmokuroot@om-gta04:~# opkg install fsosystemd
16:30.08mrmokuInstalling fsosystemd (0.0.1+gitr1+20a9ce696d738036c41298a1e185696cc701ec8f-r6.0) to root...
16:30.11mrmokuDownloading http://ladyt/shr-core/ipk//armv7a-vfp-neon/fsosystemd_0.0.1+gitr1+20a9ce696d738036c41298a1e185696cc701ec8f-r6.0_armv7a-vfp-neon.ipk.
16:30.14mrmokuConfiguring fsosystemd.
16:36.11angelox|laptopSuccessfully? :)
16:39.07GNUtoowhat's fsosystemd?
16:40.04*** join/#openmoko-cdevel pespin (~pespin@254.Red-88-28-136.staticIP.rima-tde.net)
16:40.07GNUtooI don't see it in cornucopia
16:40.09GNUtoopespin, hi
16:40.43dos1ok, i've played a bit with aurora on gta02
16:40.52pespinhi! finally I have conn from a mobile's friend sharing it hehe
16:40.55dos1now flashing shr-shr :D
16:40.55GNUtoodos1, how is it?
16:41.13dos1GNUtoo: awfuuuuuuuullyyyy sloooooooooooow
16:41.20GNUtooah ok
16:41.34dos1GNUtoo: and nonuseable anyway :D there's something wrong with telephony
16:41.44GNUtooah again?
16:41.58GNUtoomaybe something is wrong
16:42.05GNUtoolast time I looked it was not that slow
16:42.07dos1outgoing call was displayed as incoming
16:42.10GNUtoobut it was unusable the same
16:42.11GNUtoook
16:42.27dos1truly incoming call couldn't be rejected nor accepted
16:43.24GNUtoodos1, when was the build from?
16:43.36mrmokuGNUtoo: have to push it
16:43.45GNUtoook
16:43.46mrmokuGNUtoo: it will solve the firmware loading problem
16:43.49mrmokuas a first step
16:44.04GNUtooah? but we have fsodeviced for that
16:44.07dos1GNUtoo: 004
16:44.12GNUtoowith firmware loader
16:44.15GNUtoodos1, ok
16:44.21mrmokuGNUtoo: yeah, but the problem with that is a hen - egg one
16:44.23dos1added report to wiki
16:44.31mrmokufsodeviced might need a module for a plugin
16:44.38mrmokuand modules need fsodeviced as firmware loader
16:44.59GNUtoook
16:45.55mrmokuGNUtoo: all essential and basic low-level device stuff that does not need dbus should go there
16:46.07mrmokulike the n900 charging plugin too
16:46.08GNUtoook
16:48.45antrikGNUtoo: I'm still using u-boot on GTA02. not sure where I got it from though... probably not SHR
16:50.05GNUtoook
16:53.52morphismrmoku: no, it's not framebuffer restricted and currently we're using x11
16:55.46mrmokumorphis: ohh... didn't know that
16:55.50mrmokuAinulindale: ^^
16:55.56morphismrmoku: no problem
16:56.11morphismrmoku, Ainulindale: so Aurora is SHR without E17 UI but with Qt based UI
16:56.18mrmokumorphis: I have a fsosystemd now
16:56.33mrmokuI'm wondering about what plugins can move there though
16:57.03mrmokuthe n900 charging plugin has a comment     // internal (accessible for aggregate power supply)
16:57.17mrmokuwhich tells me it can't go to fsosystemd probably
16:57.42mrmoku<PROTECTED>
16:57.44morphismrmoku: whats the general idea about fsosystemd?
16:57.45mrmokuyeah
16:57.59morphisI thought it should be carry only system stuff and not device things
16:58.10morphislike firmware handling
16:58.11mrmokufirst step to have the essential critical stuff
16:58.13mrmokuyeah
16:58.19mrmokuthere's not much to go there
16:58.25mrmokucharging would have been a nice one though
16:58.30morphisreally?
16:58.34mrmokuthe earlier we can charge the better
16:58.39morphishm
16:58.53morphiswe have the power supply dbus API
16:58.55mrmokuanyway... will just push it with the firmware loader
16:58.59morphisok
16:59.07mrmokuyeah, but you can't enable/disable charging there
16:59.16morphisI thing fsosystemd should carry only some little system stuff
16:59.33morphisyes
16:59.40morphisthats some feature we should really implement
16:59.52mrmokuenable disable charging?
16:59.53mrmokuwhy that
17:00.16morphisfor example: you're in the train, laptop battery is low
17:00.28morphisand you connect your phone to have internet access via usb
17:00.39morphisthen the phone should not charge over USB
17:00.49mrmokuhmm
17:00.55mrmokuthat would be a usecase
17:01.01morphisbut it's not really important :)
17:01.05mrmokuno :P
17:01.08morphiswe have more important use cases
17:01.18morphisok, so we have a fsosystemd now
17:01.29morphisdo you converted the fsoinitd to be plugin-based?
17:01.54morphishm I dropped fsoinitd some time ago ...
17:02.08mrmokuwell in the end it's taken more from fsodeviced
17:02.27mrmokuwhen I saw fsoinitd has no plugin stuff :)
17:02.35morphisok
17:02.54morphisbut I am not sure wether fsosystemd should provide a dbus API
17:03.32mrmokuno it can't
17:03.45mrmokuwell it could, but not on startup
17:04.11mrmokudbus starts way too late
17:04.29morphisyes
17:04.52morphisbtw. I started to implement a test suite for our dbus API
17:05.09morphiswhich you can run and you have a report at the end which stuff works as it should and which not
17:05.27mrmokunice
17:05.40morphiswould also help to adjust different implementations like in the GSM domain
17:05.42morphisyes
17:06.01morphisit's something we really need even with the aim to get a stable distribution
17:06.30dos1JaMa: shr-full-om-gta02.ubi from 004 does not mount
17:07.03dos1JaMa: UBI error: process_eb: bad image sequence number 1880304218 in PEB 1969, expected 1537023111
17:07.27dos1downloading lite now
17:07.34dos1(btw. aurora ubi image worked)
17:07.52morphisdos1: aurora in the gta02?
17:08.00dos1morphis: yup
17:08.10morphisdoes it startup the UI?
17:08.19dos1yup
17:08.24dos1it's awwwfuuulllyyyy sloooooow
17:08.29dos1and has problems with telephony
17:08.36dos1but it starts and somehow works
17:10.47mrmokudinner
17:11.38morphisdos1:  :)
17:12.11morphisyes latest version (004) has problems with telephony but they are fixed and 005 should be working
17:12.38JaMamorphis: ?
17:12.39angelox|laptopmorphis: should it be so slow?
17:14.37angelox|laptopmorphis: and that is cpp version?
17:16.11GNUtoopespin, hi did I say that I fixed mplayer for ogg vorbis on om-gta02?
17:16.41pespinGNUtoo, nop, I didn't know
17:16.47pespinGNUtoo, mplayer2 or 1?
17:16.53dos1JaMa: the same problem with lite :(
17:16.54pespin2 right?
17:16.56GNUtooboth I guess
17:17.02GNUtoothe fix is in mplayer-config
17:17.08GNUtooso I tried with mplayer2
17:17.12GNUtoobut maybe it fixes 1 too
17:17.17pespinGNUtoo, hmm wait, wasn't your problem with gstreamer?
17:17.26GNUtooI've many problems.....
17:17.29pespingetting noise instead of music
17:17.31pespinlol
17:17.50GNUtooone of the problem is mplayer not playing well ogg vorbis => fixed in git
17:17.58pespinGNUtoo, buy an ukelele, I did it some days before and it helps to follow the happiness path ;)
17:18.05GNUtooother problems include n900 not working well for instance
17:18.11GNUtoolol
17:18.27JaMados1: did you use dfu-util or cleaned and flashed from uSD?
17:18.36dos1JaMa: dfu-util
17:18.58JaMapespin: can you please apply the BINDINGS/vala patch to fix label_set _before_ the big merge with API from your 2nd repo?
17:19.25dos1flashing aurora worked, flashing shr-lite or shr-full didn't
17:19.28GNUtoopespin, or maybe I should write a jamendo app for the om-gta02
17:19.34pespinJaMa, apply it in E svn?
17:19.38JaMapespin: yes
17:19.48pespinJaMa, do you have patch at hand?
17:20.00pespinas I modified it to apply for newer eflvala
17:20.05JaMapespin: so we will be able to stay with some E svn SRCREV (without extra patch) until all apps are fixed
17:20.27pespinok
17:20.41JaMapespin: 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
17:21.07morphisJaMa: I think 005 will be the next staging version and it includes my latest commit for meta-smartphone which bumps aurora SRCREV
17:21.20pespinGNUtoo, I haven't played with jamendo yey, is it good?
17:21.20morphisangelox|laptop: it's the graphic stuff which is so slow on the om-gta02
17:21.34GNUtoopespin, very, I've a jamendo app on replicant
17:21.43JaMamorphis: 004 will have it (it wasn't closed yet)
17:21.46GNUtoo(the music is very good)
17:21.48*** join/#openmoko-cdevel anarsoul (~anarsoul@212.98.189.25)
17:21.57angelox|laptopmorphis: ah ok
17:22.00JaMamorphis: and I'm rebuilding those images atm, because of dbus issue
17:22.08morphisah ok
17:22.11morphisthen it will be 004
17:22.29pespinGNUtoo, only free music right?
17:22.44GNUtoofreely redistributable yes
17:22.52JaMaactualy I've removed oll older images for armv7 because they all had wrong dbus owner :/
17:22.58GNUtoocreative commons and some other licenses
17:23.13GNUtoobut as you know CC have stuff like ND NC etc....
17:23.29GNUtoobut redistributable is good enough for me
17:23.42pespinnice
17:23.52pespinGNUtoo, lots of classical music I guess?
17:24.04GNUtoothere is some classical
17:24.11GNUtoonot only classical
17:24.23GNUtoofor classical there is also another website
17:24.29pespinI guess most of classical music is under public domain right now right?
17:24.31GNUtoomusopen
17:24.34GNUtooyes
17:24.43GNUtoobut jamendo has everything, not only classical
17:24.45pespinok :)
17:24.59pespindoes it have some kinf of API or webservice?
17:25.31GNUtooyes it does
17:25.40GNUtooelse the jamendo app wouldn't work
17:25.54GNUtooalso there is jamendo integrated in many desktop clients
17:25.56GNUtoolike totem
17:26.01GNUtooor rythmbox
17:26.38antrikJaMa: 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?...
17:26.59JaMaantrik: like wht?
17:27.09GNUtoobasically on jamendo you won't find a lot of interpretation of classical music but rather new songs including classical ones
17:27.32GNUtoo(for interpretation of classical stuff there is wikipedia, musopen etc...)
17:27.35pespinnice, I'd give a try but I have enough stuff to do with emtooth2 and etalk and all this eflvala shit.
17:27.40GNUtoook
17:27.51GNUtoomaybe just listen to the music in a desktop client then
17:28.06pespinyeah :)
17:29.11JaMagoing home, bbl
17:32.33*** join/#openmoko-cdevel NIN101 (~NIN101@2001:530::216:3cff:fe71:5e1e)
17:43.09pespinJaMa, I had to hack manually my Elementary.h as I don't have here in netbook such new elementary.
17:43.22pespinapart from that looks ok, I'll push
17:43.46JaMagood, one less efl patch in meta-efl :)
17:44.00antrikpespin: new recordings of classical music are not at all public domain
17:44.34antrikin fact, considering the time when recordings became common, you will be hard pressed to finde *any* that are public domain...
17:44.38pespinantrik, so the copyright is per recording, not per piece?
17:45.10antrikJaMa: you were talking about ffphonelog and ffalarms
17:45.47JaMaantrik: and did I say I have removed them?
17:46.11pespinJaMa, Committed revision 65990.
17:46.22JaMapespin: thx
17:47.43antrikpespin: the copyright is on a lot of things; including original composition, arrangement, performance, and even the actual recording I think...
17:48.21pespinugh what a mess then
17:48.27antrikindeed
17:48.27AinulindaleHmmm well for the aurora thingy
17:48.42AinulindaleWhy not evolve on the SHR stack basis?
17:48.52Ainulindale(and/or fork and/or ditch the current one)
17:49.14Ainulindale(this isn't a trick question)
17:49.48AinulindaleBecause at the beginning of SHR the goal was (and hopefully ever is) to do exactly that :-)
17:49.59antrikJaMa: no, but you said that you can drop them instead of adapting for newer eflvala...
17:51.30JaMaantrik: I've said that about apps nobody cares about
17:52.02JaMaantrik: and if you check the logs I've fixed all apps using wrong elm or vala/elm APIs before bumping EFL in OE..
17:52.07antrikAinulindale: the official justification is that the SHR stack is supposedly to complex for testing FSO
17:52.22JaMaantrik: and I plan to do it again if needed just to be able to use newer EFL if possible
17:52.36AinulindaleI don't care about the stack we're talking about testing features
17:52.52AinulindaleSHR is mainly a distribution with no concern for specific stacks
17:53.08AinulindaleSo if the purpose is to test all the features
17:53.19antrikJaMa: well, obviously anyone actually wanting to use it for a phone will care at least about ffphonelog...
17:53.23AinulindaleThen this UI is basically what should have been done (and supposed to be done) 4 years ago :-)
17:53.25*** join/#openmoko-cdevel sigius (~sigius@93-125-185-45.dsl.alice.nl)
17:53.49JaMaantrik: there there is no issue and I don't understand why you said I plan to remove it
17:53.58AinulindaleThat is : sensible, usable and coherent UI for phone functionnalities and settings
17:54.01JaMas/there there/then there/
17:57.02antrikJaMa: well, maybe I misread your statement. it sounded like you considered it a serious option
17:57.10antrik19: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)
17:57.15antrik19:17 < JaMa> pespin: those apps are pretty simple
17:57.16antrik19:17 < JaMa> pespin: so if someone still cares they can be fixed even with little more help then easy sed commands
17:57.19antrik19:18 < JaMa> and if nobody cares then we'll just drop them from feed :)
17:57.56antrikI didn't say you *plan* to remove them... I asked whether you are seriously considering it
17:58.50antrikAinulindale: I'm not sure what you are trying to say...
17:59.02AinulindaleI'm not trying to say something, I'm saying it :-)
17:59.37mrmoku:)
17:59.46AinulindaleThe 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?
17:59.51AinulindaleIs there a specific reasons which would explain that?
17:59.52CIA-82freesmartphone.org: 03mok 07cornucopia * r341524bc4241 10/fsosystemd/ (20 files in 7 dirs):
17:59.52CIA-82freesmartphone.org: fsosystemd: initial implementation
17:59.52CIA-82freesmartphone.org: Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
18:00.20mrmokuthe problem seems to be the complexity of the SHR phone stack
18:00.24antrik(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...)
18:00.33*** join/#openmoko-cdevel Slyon (~lukas@ppp-93-104-23-249.dynamic.mnet-online.de)
18:00.39Slyonhey
18:00.43mrmokuyo Slyon
18:00.46morphisAinulindale: it's not a fork
18:00.59morphisAinulindale: it's just a playground for me and mickeyl
18:01.04Ainulindalemrmoku: What about the "complexity of the SHR phone stack"?
18:01.17AinulindaleBecause this expression sounds to me as a "me don't like C me do other stuff"
18:01.26mrmoku:)
18:01.32AinulindaleJust trying to find out the goal or purpose behind that
18:01.34mrmokuI'm not the right one to talk with here :P
18:01.39Ainulindalemrmoku: meh
18:01.43Ainulindalemrmoku: you suck! :-)
18:01.48mrmokulikes C ;)
18:01.55Slyonmrmoku, can you tell me what the "re"-Regex and the "tere"-Regex needs to describe in a fsogsmd plugin when overwriting an AT command?
18:01.56Ainulindalemorphis: well then please enlighten me :-)
18:02.03Ainulindale(bad pun sorry)
18:02.10Ainulindale:->
18:02.23mrmokuSlyon: uhh
18:02.24Ainulindalemrmoku: C is for men!
18:02.27mrmokunot without looking
18:02.27morphisAinulindale: in general mickeyl and I wanted a very tiny stack to play with FSO and Qt Quick
18:02.36Ainulindalemrmoku: With a nice heavy pair... of coffee pots!
18:02.42morphiswith not much stuff in the stack
18:02.48mrmokuand some beer in between :)
18:02.51Ainulindalemorphis: What's "not much stuff" ?
18:02.57AinulindaleBecause if in the end you implement all the features
18:03.02AinulindaleI'd say there'll be more stuff
18:03.03Slyonmrmoku, you did it in modem_option_gtm601 while overwriting +COPS
18:03.05morphiscomplete X11 with a lot of daemons and applications
18:03.13mrmokuSlyon: yeah, but my memory sucks a lot :P
18:03.21Ainulindalemorphis: Well then isn't it the goal of the distro and not the stack?
18:03.29GNUtooAinulindale, C is a nice high level programming language
18:03.45AinulindaleWhat prevented you from using the current stack although stirpped down to the bare needed daemons?
18:04.26AinulindalePlease note that I'm not saying it's a bad idea or criticizing there
18:04.34AinulindaleJust trying to have an understanding of the reason
18:04.58AinulindaleBecause I witnessed so many "me not like me do yet another thingy" events in this community...
18:05.23*** join/#openmoko-cdevel plotr (~name@dnm.60.46.188.95.dsl.krasnet.ru)
18:05.59mrmokuSlyon: match = tere.match( response, 0, out mi );
18:06.15mrmokuprobably te = Terminal Equipment
18:06.37Slyonmrmoku,  so tere = response from modem
18:06.38morphisAinulindale: first it's not another distro
18:06.45morphisAinulindale: it's SHR with another UI
18:07.00morphisAinulindale: mickeyl and I was impressed by the power you have with Qt Quick
18:07.20mrmokuSlyon: yeah, regex that should match the modem's response
18:07.32Ainulindalewell do you really feel it's worth time and effort to build yet another UI morphis?
18:07.38morphisAinulindale: an we wanted a better replacement for zhone2
18:07.50morphisAinulindale: yes and no
18:08.05morphisAinulindale: you are right it's much time we need to get it working
18:08.10Slyonmrmoku, that makes it easy, as AT+CHUP shouldn't give any response
18:08.53morphisAinulindale: but in detail you are really was with Qt Quick to implement new applications and features
18:09.21Ainulindalemorphis: I didn't understand this last sentence
18:09.46morphiss/need/needed/
18:10.05mrmokuSlyon: hehe, yeah
18:10.29Ainulindalemorphis: I didn't understand the last sentence, not the penultimate :-)
18:10.44morphisAinulindale: let's not continue this discussion right now as I run out of time
18:11.07morphisAinulindale: but in detail you are really fast with Qt Quick to implement new applications and features
18:11.16morphisthats the correct sentence
18:11.22morphissorry for that
18:11.26Ainulindaleno problem
18:11.32*** join/#openmoko-cdevel toams (~tommi@94-224-20-159.access.telenet.be)
18:11.39morphisAinulindale: don't give the Aurora project too much importance
18:11.47morphisthe focus of the community is still at the SHR UI
18:11.53morphisand thats ok and good
18:11.53JaMaantrik: ok, then we both misunderstood each other a bit..
18:12.00Ainulindalemorphis: well
18:12.07Ainulindalemorphis: the SHR ui was crap when I stopped working on SHR
18:12.12Ainulindalemorphis: so I don't care about that :-)
18:12.24AinulindaleI'm just trying to have a good vision of what's done and what'll be interesting
18:12.35morphisok
18:12.47morphisthen we should talk again when I have more time
18:12.49angelox|laptopmorphis: please, when you have time, check the about app i did create :D
18:13.04morphisangelox|laptop: which one?
18:13.21angelox|laptopin settings-rework app-about my three last commits
18:13.30morphisangelox|laptop: ok
18:13.38angelox|laptopthere's an inma in aurora's screenshots page
18:13.40JaMaantrik: 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 :)
18:13.43angelox|laptops/inma/image/
18:14.32mrmokuJaMa: there is started phonelog integrated in libphone-ui-shr... would just have to finish it :P
18:14.39morphisAinulindale: so you are back to the project now?
18:14.50AinulindaleCertainly not
18:15.07AinulindaleI don't have neither time or frame of mind for it :-)
18:15.11morphisok
18:15.12AinulindaleDo unit tests, do QA
18:15.17AinulindaleThen maybe I'll come back
18:15.20morphis:)
18:15.21AinulindaleMeanwhile, NO GO :-)
18:15.23JaMamrmoku: hehe, if pespin is right then maybe it will be easier to finish it then converting ffphonelog to new eflvala API :)
18:15.29mrmokuAinulindale: but you will certainly participate in the release part - whenever that is, right? :)
18:15.47AinulindaleWell if we're still alive by then, sure
18:15.51JaMamrmoku: but Lukas is still sending patches for ff* so I belive he will fix it himself
18:15.56Ainulindale:-p
18:15.59mrmoku:P
18:16.13Ainulindalemrmoku: but you know how it is
18:16.20AinulindaleIf there is no clear direction/leadership
18:16.23Ainulindalewith one firm goal
18:16.32AinulindaleAnd if everybody does its thing by itself
18:16.41AinulindaleIt won't amount to much sadly because it won't have any coherence
18:16.46JaMamrmoku is respected and beloved leader! :)
18:17.06Ainulindale(Not saying that it's bad that there are other initiatives there, only that it kills planification)
18:17.32JaMaand he will also buy me nice BMW on our way to Essen I belive :)
18:17.43mrmokunever felt like being the leader... probably a wrong thing
18:18.07antrikJaMa: I see. misunderstanding indeed :-)
18:18.14morphiswe have no one who is in the positon of a leader
18:18.27mrmokuAinulindale: that's all stuff we will discuss soon in a very nice location :)
18:18.30morphisjust a lot of people with a lot of thing to do :)
18:18.44mrmokuAinulindale: to get a plan
18:18.59Ainulindalewell
18:19.04Ainulindaletalking is one thing
18:19.08Ainulindaleenforcing it is another one
18:19.23Ainulindaleremember the heated discussion we had when I was still working? :-)
18:19.29Ainulindales/ssion/ssions/
18:19.52mrmokuthe french - french discussions? ... yeah, how could I forget :P
18:19.56Ainulindalesadly every project needs a leader even though it's not enjoyable nor rewarding
18:20.13Ainulindalemrmoku: meh ! :-)
18:20.26AinulindaleBy the way I have no news about him (ptitjes)
18:20.42AinulindaleHe moved in the south of france a while back that's all I know
18:21.05mrmokuI think he showed some signs of activity somewhere... not in here though
18:21.09Ainulindalevala?
18:21.16mrmokulibgee I think
18:21.32AinulindaleWell I hope he'll stop hopping from project to project one day :-)
18:21.44mrmokuas long as he's happy :)
18:21.47AinulindaleYep
18:21.52AinulindaleI wasn't at the time though
18:22.00AinulindaleIt's hard to say no to someone with ideas
18:22.06AinulindaleEspecially in FLOSS communities
18:23.33GNUtoomorphis, I've an issue with fsousaged on crespo:
18:23.34GNUtoo2011-10-18T02:56:24.611924Z [INFO]  fsousaged : received signal -11, shutting down...
18:23.39GNUtoocontinuously
18:23.40GNUtoohmmm
18:23.43Ainulindalemrmoku: 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 :-)
18:23.54Ainulindalemrmoku: so draw your own conclusions from that
18:24.21antrikAinulindale: 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 :-)
18:24.47Ainulindalewell no
18:24.49Ainulindalethat's not a problem
18:24.50GNUtoomaybe I should try a new iimage?
18:24.57Ainulindales/a /the /
18:24.58*** join/#openmoko-cdevel SabotageAndi (~SabotageA@h081217018227.dyn.cm.kabsi.at)
18:25.19AinulindaleThe 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
18:25.31AinulindaleAnd then you have each and every developer doing his own thing
18:25.34AinulindaleAnd no common thing
18:25.40AinulindaleHence no coherence, no planning, no deliverable
18:25.47Ainulindale=> no usable phone :-)
18:26.00angelox|laptopmorphis: and please tell me what to work now (since settings-rework is finished)
18:26.28*** join/#openmoko-cdevel nschle85 (~kvirc@178-27-184-116-dynip.superkabel.de)
18:26.35Ainulindalemrmoku: but IMHO that's the thin line between a project and a "for free" project
18:26.43AinulindaleYou can't say no but you must say no
18:27.23mrmokuhmm
18:27.44mrmokuAinulindale: what do you mean by "for free" ?
18:28.52Ainulindalewell
18:28.55Ainulindaleyou're not paid for SHR
18:29.02Ainulindaleyou're doing that because you want to enjoy yourself and build something
18:29.14Ainulindaleso it's hard to be assigned to tasks you don't like
18:29.20Ainulindale(such as QA, unit testing)
18:29.22*** join/#openmoko-cdevel KaZeR (~kazer@74.43.195.77.rev.sfr.net)
18:29.23Ainulindaleeven though it's necessary
18:29.27mrmokuahh... difference between some comercial project and one like this one with volunteers
18:29.30mrmokuyeah
18:29.32Ainulindaleyep
18:29.45antrikAinulindale: 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...
18:29.47mrmokuindeed yeah
18:29.48AinulindaleIn my case, I didn't like posting in ML and blogs and such and forced myself to
18:29.51AinulindaleAnd it was annoying
18:30.07Ainulindaleantrik: well you rephrased what I just said :-)
18:30.17pespinhmm that remembers me I haven't posted in the shr blog since august lol
18:30.19Ainulindaleantrik: but that's why I created the core team
18:30.34AinulindaleThe core team having the power to talk about stuff, decide, and impose the choice
18:30.53AinulindaleBecause in the end that's what necessary
18:31.26AinulindaleA group of able and experienced people making choices with one of them being the guy taking the blows
18:31.34Ainulindale(not the blowjobs, just plain actual blows)
18:31.45AinulindaleAs in every project in fact
18:31.57Ainulindale(but again, that's only my humble theory)
18:32.41antrikI 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
18:33.31Ainulindaleantrik: the core team is there to have heated discussion to come up with a consensual compromise
18:33.34Ainulindalethen the leader imposes
18:33.45AinulindaleAt least that's what I did when I was the (self-attributed) leader
18:34.01AinulindaleAnd it (almost) worked
18:34.21AinulindaleBut my solution is only my solution, I don't pretend it to be the best
18:35.56AinulindaleIMHO (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
18:36.03AinulindaleA huge mess
18:36.17Ainulindale(compared to parallel spaghetti that is :-p)
18:36.45mrmokuyou're putting the spaghetti in parallel before eating them? ;)
18:37.57AinulindaleObviously yeah I'm insane
18:38.04Ainulindale(No: I don't eat spaghetti)
18:38.09mrmoku:P
18:38.12mrmokuI have too
18:38.15mrmokuoften
18:38.28GNUtoo/sbin/spa-getty ?
18:38.34AinulindaleBut I'm too fond of logical architectures well thought through and through
18:39.06antrikheated discussions are possible without a core team ;-)
18:39.22AinulindaleYeah but then N > S
18:39.33Ainulindaleand you want to work with people who'll be motivated enough to do the dirty work
18:39.46Ainulindalein order to ensure that in the end the work gets done and that for discussions S > N
18:39.49*** join/#openmoko-cdevel Heinervdm (~thomas@pD9E1521A.dip.t-dialin.net)
18:40.00AinulindaleBeen there done that :-)
18:40.30AinulindaleBecause in the end even though you may deliver something not perfect
18:40.33AinulindaleYou'll deliver something
18:40.45AinulindaleAnd if it needs modifications, it's never too late anyway (after the release ! :-p)
18:41.50antrikwell, 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
18:42.16GNUtoothere are maintainers tough
18:43.39Ainulindaleantrik: there is a leader, there is a kind of "referee"
18:43.42mrmokuindeed many subsystems all with maintainer(s) and there own mailing list for the heated discussions
18:43.52Ainulindaleantrik: and you're talking kernel which is far more  difficult than a mere UI
18:44.09Ainulindaleplus what the other guys said
18:44.12Ainulindale:-)
18:44.43Ainulindaleantrik: again, not saying I have THE solution there, just trying to explain what I think is difficult in this kind of project
18:45.09antrikmrmoku: most of the subsystems in turn have a clear leader and no core team
18:45.37Ainulindaleantrik: yeah but in this case it's almost the leader's job
18:45.54Ainulindaleantrik: and having leaders might be problematic (cf. Theo de Raadt)
18:46.04GNUtoolol
18:46.06Ainulindaleantrik: the core team is also there to be a buffer in order to prevent egomaniacs
18:46.30AinulindaleAsk to mrmoku how long I talked with him about my problem with developers in SHR and if I was alone in thinking that
18:47.28AinulindaleIt feels more democratic that way, some kind of collective intelligence
18:47.47AinulindaleAnd it forces members to understand they have some kind of responsibility
18:50.19*** join/#openmoko-cdevel NuttyBunny (~cnegrete@91-r9-r1m.bb.itelcel.com)
18:50.48nschle85Ainulindale: what was your problem with developers in shr ?
18:52.04CIA-82SHR: 03lukasmaerdian 07meta-smartphone * r114bfca0a325 10/meta-fso/recipes-freesmartphone/serial-utils/pty-forward.bb: meta-fso: add non-native pty-forward version
18:54.19antrikAinulindale: I don't really believe in democracy in managing free software projects. it causes endless infighting, and prevents true innovation
18:54.46Ainulindaleantrik: well it wasn't democracy per se
18:54.54Ainulindalekind of an oligarchy
18:55.01Ainulindalebut with cooptation
18:55.07Ainulindaleanyways I have to eat, be back in a while
18:55.11antrikunlike 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.
18:55.18GNUtooagain some strlen on NULL strings
18:55.27nschle85antrik: or fork :-)
18:55.48GNUtoohttp://www.pastie.org/private/zzl9yydxhht3m9azumeeq
18:56.07antriknschle85: right. that's one way of working on another project :-)
18:56.22antrik(usually preferable to starting from scratch)
18:57.01nschle85see Hudson, LibreOffice, XFRee ....
18:59.33Ainulindaleit's not always a good thing
19:00.41GNUtooxorg was a good thing
19:01.03nschle85GNUtoo: agree but forking often reduces manpower
19:05.48*** join/#openmoko-cdevel ThibG (~ThibG@81-64-18-234.rev.numericable.fr)
19:06.06antriknschle85: not really. usually the branch with the better leadership (whichever one it is) quickly comes out on top, and the other dies off.
19:06.21GNUtoodepends
19:06.37GNUtooin xorg it took the project ahread
19:06.48antrikmany projects actually gained *more* developers by forking and thus getting rid of poor leadership
19:06.58GNUtoothere was the split(monolithic xorg -> modular xorg)
19:06.59GNUtooetc...
19:19.59*** join/#openmoko-cdevel radek_ (~radek@63.120.broadband10.iol.cz)
19:34.56*** join/#openmoko-cdevel KaZeR (~kazer@74.43.195.77.rev.sfr.net)
19:44.49*** join/#openmoko-cdevel NuttyBunny (~cnegrete@200.95.163.61)
20:17.39GNUtoomorphis, I've found why it fails but I've no idea how to fix
20:17.40GNUtooin:
20:17.56GNUtoofsousaged/src/plugins/dbus_service/plugin.vala:
20:18.23GNUtoothis.system_action( action );
20:18.26GNUtooaction can be null
20:18.37GNUtooand system_action is a signal
20:18.46GNUtooso that creates the trace I shown before
20:18.49GNUtoohi mickeyl
20:19.04GNUtooI guess that's related to the vala upgrade
20:21.40morphisGNUtoo: I know this error
20:22.01GNUtoook
20:22.18GNUtoocan you fix it? or is it me that didn't rebuild or something like that?
20:22.26morphisyou need vala-0.14.7-... from here http://downloads.freesmartphone.org/vala-0.14.1.7-3673f.tar.bz2
20:22.37morphisit's already included in OE
20:22.43GNUtoook so I'll rebuild
20:22.49morphischeck if you building with this vala version
20:23.02morphisif not rebuild vala and then all fso stuff
20:23.08GNUtooI think I built with an old vala
20:23.17morphisyes
20:23.59GNUtoothanks a lot
20:24.05morphisno problem :)
20:26.10morphisthats my job as FSO developer :)
20:41.01mrmokumorphis: a FSO developer is what I need now :P
20:41.19mrmokumorphis: do fso daemons need /dev/pts ?
20:49.22*** join/#openmoko-cdevel nschle85 (~nschle85@178-27-184-116-dynip.superkabel.de)
22:13.53*** join/#openmoko-cdevel NuttyBunny (~cnegrete@200.95.163.83)
22:38.59*** join/#openmoko-cdevel JaMa (~martin@94.230.152.246)
23:05.38*** join/#openmoko-cdevel alexxy[home] (~alexxy@gentoo/developer/alexxy)
23:22.52*** join/#openmoko-cdevel dos1|N900 (~dos@unaffiliated/dos1)
23:48.17*** join/#openmoko-cdevel nslu2-log (~nslu2-log@limax.nslu2-linux.org)
23:51.57*** join/#openmoko-cdevel fgau (~fgau@webbox1220.server-home.net)
23:52.03*** join/#openmoko-cdevel Robi_ (robi@toldyouso.com)
23:52.33mickeylmrmoku: IIRC only those which open a pty, i.e. fsogsmd for some configurations

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.