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.25 | pabs3 | wonders 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.00 | mrmoku | moin |
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.14 | JaMa | moin |
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.01 | CIA-82 | SHR: 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.47 | morphis | heyho |
09:07.55 | morphis | mickeyl: ping |
09:07.58 | CIA-82 | SHR: 03Martin.Jansa 07shr-chroot * r9c39ed37ceb0 10/OE/ (13 files): sync scripts and bashrc from 64bit |
09:09.05 | JaMa | heyho |
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.14 | mrmoku | JaMa: I installed latest, closed staging and will use it as daily now |
09:25.29 | mrmoku | so far it looks good |
09:25.53 | mrmoku | apart from the keyboard not popping up automatically anymore |
09:26.10 | mrmoku | dunno if that changed in elementary and has to be requested explicitely now |
09:26.27 | mrmoku | that is kind of bad for the first start wizard... you can't pop it up manually there :P |
09:29.31 | JaMa | n900 or gta? |
09:29.56 | mrmoku | gta02 |
09:30.49 | mrmoku | I installed 003 on n900 too |
09:30.54 | mrmoku | did not boot on first try though |
09:30.58 | mrmoku | have to look into it |
09:31.05 | mrmoku | probably just the SD not mounted correctly |
09:31.14 | 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 :) |
09:31.59 | *** join/#openmoko-cdevel SabotageAndi (~SabotageA@h081217018227.dyn.cm.kabsi.at) |
09:32.36 | mrmoku | indeed SD was not in properly |
09:32.39 | mrmoku | now 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.25 | mrmoku | and has the backlight issue |
09:49.16 | pespin | JaMa, hi! I pushed your emtooth2 stuff, rev 164 |
09:50.35 | mrmoku | JaMa: no usb network either... that makes it difficult :) |
09:50.55 | *** join/#openmoko-cdevel otypoks (~otypoks@host-5db0d228.sileman.net.pl) |
09:53.02 | mrmoku | bbl |
10:06.06 | *** join/#openmoko-cdevel Martix (~martix@134.89.broadband12.iol.cz) |
10:17.06 | JaMa | mrmoku: 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.37 | CIA-82 | SHR: 03Martin.Jansa 07shr-chroot * re6c447750dac 10/var/ (7 files in 3 dirs): bitbake upgrade |
10:28.01 | CIA-82 | SHR: 03Martin.Jansa 07shr-chroot * r3a71034f33cc 10/ (36 files in 12 dirs): bitbake upgrade |
10:28.54 | dos1 | http://build.shr-project.org/tests/site/ |
10:29.24 | dos1 | i think only shr-core-staging support is left (selecting other image than latest) |
10:30.09 | JaMa | dos1: latest shr-core-staging not always have images |
10:30.20 | morphis | dos1: the site looks really great! |
10:30.45 | dos1 | JaMa: yup, so i have to suport that somehow |
10:31.13 | dos1 | morphis: :) |
10:31.26 | morphis | HTML5 is a great thing :) |
10:34.39 | morphis | JaMa: btw. we should add the image + kernel filename to the list add http://shr-project.org/trac/wiki/StagingTests |
10:34.51 | morphis | JaMa: as the Aurora, SHR Full, SHR Lite can be used |
10:34.56 | morphis | + the different kernels |
10:36.51 | JaMa | we can consider Lite and Full the same functionality wise imho.. but I'll add shr/aurora as special type for 004 |
10:38.35 | GarthPS | hi huys. nice work ! :) |
10:38.39 | *** join/#openmoko-cdevel mickey_office (~mickey@business-092-079-168-007.static.arcor-ip.net) |
10:40.15 | 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 : |
10:40.18 | GarthPS | ERROR: libmad was skipped: because it may require a commercial license to ship in a product (listed in COMMERCIAL_LICENSE) |
10:40.31 | GarthPS | where do I set COMMERCIAL_LICENSE and to what ? |
10:41.49 | JaMa | to empty in local.conf |
10:42.06 | JaMa | there is an example i belive in latest local.conf from SHR |
10:42.58 | 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 |
10:43.15 | morphis | JaMa: ok |
10:47.15 | *** join/#openmoko-cdevel otypoks_ (~otypoks@host-5db0d228.sileman.net.pl) |
10:48.12 | morphis | JaMa: and how do you build the several testing images? |
10:49.49 | JaMa | the process is still the same only rsync after build is different |
10:50.42 | 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" |
10:50.50 | 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 |
10:50.54 | CIA-82 | SHR: 03morphis 07meta-smartphone * r0418bb9eff98 10/meta-aurora/recipes-aurora/aurora/aurora-base.inc: meta-aurora: aurora-base: bump SRCREV |
10:51.05 | 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 |
10:51.05 | JaMa | and for cycle to call it for each machine |
10:51.11 | morphis | JaMa: 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.43 | GNUtoo | I think I have the fix for mplayer |
11:09.07 | GNUtoo | I'll push it |
11:10.20 | morphis | GNUtoo: heyho |
11:10.26 | morphis | GNUtoo: I have ALSA with dmix working |
11:10.35 | morphis | with the android kernel |
11:10.40 | morphis | and without broonie modifications |
11:10.56 | morphis | s/broonie/broonie's/ |
11:11.37 | GNUtoo | morphis, ok nice |
11:11.51 | morphis | GNUtoo: you just need to disable CONFIG_S5P_INTERNAL_DMA |
11:11.58 | GNUtoo | ah ok |
11:12.13 | GNUtoo | what about the controls ? |
11:12.16 | morphis | I played a little bit with it playing multiple audio files at the same time |
11:12.29 | morphis | we can use the Android set of controls |
11:12.32 | GNUtoo | ok |
11:12.35 | morphis | would be easier |
11:12.44 | morphis | otherwise I got it working with broonie's kernel too |
11:12.51 | GNUtoo | android set of controls are somehow buggy |
11:12.58 | morphis | really? |
11:13.09 | GNUtoo | yes I know why there is bad sound sometimes |
11:13.19 | GNUtoo | I suspect that some routing paths are forbidden |
11:13.35 | GNUtoo | in the sense that if you go there it put the CODEC in a bad state |
11:13.42 | GNUtoo | and after you need to reboot |
11:14.00 | GNUtoo | I've mplayer2 working on om-gta02 btw |
11:14.04 | morphis | great |
11:14.20 | morphis | so what do you think, should we use android controls or the real ones from broonie's kernel? |
11:14.31 | GNUtoo | hmmm |
11:14.36 | GNUtoo | the android ones may be buggy |
11:14.43 | morphis | I don't have any clue how to figure out which controls we need to set for getting call audio working |
11:14.43 | GNUtoo | the bronie ones may break your device |
11:14.48 | morphis | yes |
11:14.56 | *** join/#openmoko-cdevel erwt (~erwt@114.143.160.125) |
11:14.56 | morphis | so I think we should stay with android ones |
11:15.00 | GNUtoo | ok |
11:15.04 | morphis | but we need to fix the alsamixer-thing |
11:15.10 | GNUtoo | yes |
11:15.23 | GNUtoo | but maybe that can be worked arround |
11:15.23 | morphis | so we don't need to set the controls to their correct values everytime someone wants to play audio |
11:15.25 | GNUtoo | with amixer |
11:15.32 | morphis | how? |
11:15.42 | GNUtoo | simply by setting the value directly |
11:16.01 | GNUtoo | and not by cycling trough the values |
11:16.03 | GNUtoo | however |
11:16.22 | GNUtoo | it doesn't fix the fact that it removes the settings at .close |
11:17.06 | morphis | yes |
11:17.19 | morphis | and for this we need to find a work-around |
11:17.59 | GNUtoo | no |
11:18.04 | GNUtoo | we need to fix it in the code |
11:18.19 | GNUtoo | it would be easier |
11:19.21 | morphis | ok, do you know where? |
11:19.37 | morphis | btw. whats the state for wifi? |
11:20.13 | morphis | and about your not-working telephony on crespo device: it works fine here with ${AUTOREV} |
11:20.42 | JaMa | GNUtoo: please be more carefull with extra newlines on wiki, ie: http://www.shr-project.org/trac/wiki/StagingTests?action=diff&version=19 |
11:21.00 | morphis | and I am currently taking a look at your code for setting up the GPRS conneciton with android |
11:21.04 | GNUtoo | morphis, ok |
11:21.44 | GNUtoo | JaMa, ok btw music fails and I've a fix |
11:22.04 | JaMa | good |
11:22.36 | GNUtoo | the fix is a better mplayer.conf |
11:22.44 | GNUtoo | with alsa and tremor instead |
11:22.47 | GNUtoo | but only for om-gta02 |
11:23.15 | morphis | GNUtoo: do you have some log output for me about the PDP part in the ril? |
11:23.27 | GNUtoo | morphis, yes let me look |
11:24.22 | morphis | and you need to listen for IPC_GPRS_IP_CONFIGURATION unsolicited response message |
11:25.37 | GNUtoo | ok |
11:25.43 | GNUtoo | I did that instead: |
11:25.50 | GNUtoo | netcfg dhcp rmnet0 |
11:25.53 | GNUtoo | or something like that |
11:25.59 | morphis | no |
11:26.03 | morphis | that doesn't work |
11:26.10 | GNUtoo | ahhh ok |
11:26.12 | morphis | you need to use the IP settings which comes with the response |
11:26.16 | GNUtoo | ok |
11:26.30 | GNUtoo | it worked on qualcomm devices tough |
11:26.33 | GNUtoo | that's why I did it |
11:26.36 | morphis | hm |
11:26.42 | morphis | for me it didn't worked |
11:27.55 | GNUtoo | ok |
11:30.17 | GarthPS | JaMa: thx! |
11:30.27 | JaMa | GarthPS: ? |
11:30.28 | GarthPS | don't know what is commercial licence.. |
11:30.32 | JaMa | ah |
11:31.37 | GarthPS | JaMa: and byt the way what is this for ? "export BBFETCH2=True" |
11:31.49 | GNUtoo | morphis, http://www.pastie.org/private/nmvqtauyle3s19wgvbdd7w |
11:32.57 | morphis | GNUtoo: you get a IPC_GPRS_IP_CONFIGURATION so PDP context is up |
11:32.59 | GNUtoo | GarthPS, I guess COMMERCIAL_LICENSE is for not putting patent-infridging code in the product(like for instance mp3 encoder/decoder) |
11:33.05 | GNUtoo | ok thanks |
11:33.12 | GNUtoo | I just need to listen to the IP then |
11:33.32 | GNUtoo | JaMa, am I right about COMMERCIAL_LICENSE? |
11:33.48 | GarthPS | yeah I was thinking about that .. |
11:34.26 | morphis | GNUtoo: 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.49 | GNUtoo | yes I'll do that |
11:34.59 | GNUtoo | altough I'll commit the gta02 stuff before |
11:35.29 | morphis | ok |
11:35.41 | JaMa | GNUtoo: yes something like that |
11:36.04 | JaMa | GarthPS: to select fetch2 instead of older fetch1 implementation (which is not supported by oe-core) |
11:37.03 | GarthPS | ok thx |
11:44.07 | mrmoku | dos1: yo, you rock :-) |
11:47.52 | *** join/#openmoko-cdevel wolfspraul (~wolfsprau@222.130.123.99) |
11:49.18 | morphis | GNUtoo: <morphis> ok, do you know where? |
11:50.55 | GNUtoo | no I don't, I'll look after mplayer + data in replicant |
11:51.43 | 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 |
11:51.44 | 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 |
11:53.42 | morphis | GNUtoo: ok |
11:54.00 | *** join/#openmoko-cdevel dos1 (~dos@unaffiliated/dos1) |
11:54.31 | dos1 | pabs3: http://build.shr-project.org/tests/site/MISO-info.txt |
11:59.39 | 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 |
12:04.37 | pabs3 | dos1: I see, not something that could ever go into Debian then |
12:10.10 | mrmoku | mickey_office: any suggestion what we could do about our 'fsodeviced comes too late to load firmware' problem? |
12:11.11 | morphis | mrmoku: what means fsodeviced comes too late? |
12:11.38 | mrmoku | morphis: modules being loaded and requesting firmware before fsodeviced is around |
12:12.20 | mrmoku | sure we can try to move fsodeviced to start a tad earlier or module loading to come a bit later |
12:12.34 | mrmoku | dunno if that is the correct solution generally speaking |
12:12.57 | morphis | hm |
12:13.03 | morphis | about whic modules we're talking here? |
12:13.23 | mrmoku | on n900 it is etk8... |
12:13.28 | JaMa | or let modules and fsodeviced start in paralel :) |
12:14.54 | morphis | hm |
12:15.04 | morphis | etk8 is required for network? |
12:16.09 | mrmoku | I don't think so |
12:16.39 | mrmoku | morphis: I'm more concerned in general |
12:16.54 | mrmoku | what if fsodeviced needs some module for some plugin? |
12:17.03 | mrmoku | then we would have to load modules first |
12:17.07 | mrmoku | and then fsodeviced |
12:17.16 | morphis | yes but if the module requires a firmware then .. |
12:17.20 | morphis | we have a problem |
12:17.22 | morphis | you are right |
12:17.26 | mrmoku | that's the point, yeah |
12:17.35 | morphis | maybe we need something like a deffered plugin loading |
12:17.58 | mrmoku | or exctract the firmware loader into a small thing on it's own |
12:18.02 | morphis | yes |
12:18.06 | morphis | but for the moment |
12:18.15 | morphis | who requires the etk8 module? |
12:18.20 | pabs3 | isn't udev the thing for loading firmware? |
12:18.22 | morphis | so we can decide what we can do for the moment |
12:18.27 | morphis | pabs3: not in SHR |
12:18.32 | morphis | we're not using udev anymore |
12:18.48 | pabs3 | huh, why is that? |
12:19.51 | morphis | as we're using devtmpfs + fsodeviced for that |
12:19.58 | morphis | fsodeviced has a firmware loader |
12:21.29 | 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 |
12:21.33 | mrmoku | .freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/libexec/dbus-daemon-launch-helper: Success; trying to enable the resource unconditionally |
12:21.55 | mrmoku | root@nokia900:~# ls -l /usr/libexec/dbus-daemon-launch-helper |
12:21.55 | mrmoku | -rwsr-xr-- 1 root root 185056 Nov 21 07:02 /usr/libexec/dbus-daemon-launch-helper |
12:21.57 | mrmoku | damn |
12:22.00 | morphis | :) |
12:22.25 | mrmoku | JaMa: that explains the backlight problem I think |
12:24.50 | JaMa | mrmoku: not for me as I was extracting image with --numeric-owner |
12:25.10 | JaMa | -rwsr-xr-- 1 root messagebus 185056 Nov 20 12:42 /usr/libexec/dbus-daemon-launch-helper |
12:26.06 | mrmoku | JaMa: I have that --numeric-owner in my install script too |
12:26.21 | JaMa | which image did you took? |
12:26.22 | JaMa | 003? |
12:26.26 | mrmoku | and fixing the permissions and restarting fsodeviced makes the backlight work |
12:26.29 | mrmoku | yeah 0003 |
12:26.30 | mrmoku | -0 |
12:27.32 | 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 |
12:27.40 | mrmoku | JaMa: -rwsr-xr-- 1 root root 185056 Nov 21 08:02 dbus-daemon-launch-helper |
12:27.43 | mrmoku | yeah :) |
12:28.44 | 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 |
12:28.58 | JaMa | killling 004 image build |
12:29.09 | mickey_office | mrmoku: can you recap the problem for me? missing context |
12:29.17 | mickey_office | ah, i guess i know |
12:29.24 | mickey_office | fsodevice not started @ module loading time? |
12:29.31 | mrmoku | mickey_office: fsodeviced is needed when modules are loaded that request a firmware |
12:29.33 | mickey_office | only one solution thereĀ
start it earlier. |
12:29.34 | mrmoku | yeah, exactly |
12:29.49 | mrmoku | on the other hand fsodeviced might need a module for some plugin |
12:30.02 | morphis | mickey_office: good you are here |
12:30.02 | mrmoku | some kind of hen-egg thingie |
12:30.09 | mickey_office | mrmoku: not much of a problem |
12:30.27 | mickey_office | we can teach fsodeviced to rerun a detection phase when a new module is loaded |
12:30.30 | mickey_office | it can detect that via kobject |
12:31.21 | mrmoku | oh, diego woke up... brb |
12:32.53 | morphis | mickey_office: you have some time right now for the vala things? |
12:33.37 | mrmoku | mickey_office: ok |
12:36.02 | JaMa | mrmoku: I think I've found the problem with dbus owner in sstate (missing --numeric-owner there too) |
12:36.11 | mrmoku | JaMa: great |
12:39.22 | mickey_office | morphis: yo |
12:41.00 | mrmoku | rc0.d/K27fsodeviced rc1.d/K27fsodeviced rc2.d/S27fsodeviced rc3.d/S27fsodeviced rc4.d/S27fsodeviced rc5.d/S27fsodeviced rc6.d/K27fsodeviced |
12:41.04 | mrmoku | rcS.d/S04modutils.sh |
12:41.07 | radekp | mrmoku: you can embed firmware to modules, if you dont have licensing problem with that |
12:41.08 | 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 |
12:41.34 | mrmoku | radekp: hmm... I think we would have issues with that |
12:42.32 | mrmoku | would be the most elegant solution though :) |
12:42.38 | *** join/#openmoko-cdevel jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
12:43.33 | mrmoku | mickey_office: would it be feasible to make fsodeviced start without dbus? and detect when dbus gets started? |
12:43.38 | morphis | mickey_office: so with which one do we want to start? |
12:44.02 | radekp | also starting "udevd", then modprobe "module_which_needs_fw", kill udevd was working |
12:44.14 | mrmoku | :P |
12:44.19 | mrmoku | radekp: that I call a hack ;) |
12:44.24 | radekp | too :) |
12:44.38 | radekp | but i think you can write small program that just calls libudev |
12:45.01 | radekp | IIRC udev is written as library, you can use it just for FW loading |
12:45.29 | radekp | has the same problem on QtMoko |
12:45.35 | mrmoku | yeah, but before we do that we could extract fsodeviceds firmware loader |
12:45.41 | mrmoku | radekp: hmm... interesting |
12:46.27 | radekp | i am also not using normal udev anymore |
12:46.28 | mrmoku | radekp: we should find a solution then that works for you too |
12:46.34 | mrmoku | yeah, we neither |
12:46.45 | mrmoku | are you using fsodeviced? |
12:46.49 | mickey_office | mrmoku: i don't know offhand whether that would work, worth a try |
12:47.13 | mrmoku | mickey_office: starting after dbus is a quite limiting factor in moving fsodeviced early :) |
12:47.18 | radekp | i have FSO just as optional dependency |
12:47.42 | mickey_office | mrmoku: i see. well, i have to think about that |
12:47.46 | radekp | i do images based on debian stable, which does not have FSO |
12:47.50 | mrmoku | mickey_office: ok :) |
12:47.52 | GNUtoo | JaMa, I tought that adding mplayer-common/om-gta02 marked it to machine-arch automatically |
12:48.07 | GNUtoo | Architecture: all |
12:48.23 | GNUtoo | that's what I have with opkg info mplayer-common on target |
12:49.00 | JaMa | did you bump PR or -force-reinstall it? |
12:49.29 | JaMa | not sure if inherit all arch doesn't override mplayer-common/om-gta02 in SRC_URI.. |
12:51.19 | GNUtoo | ok |
12:51.47 | GNUtoo | I'll machine arch it for om-gta02 and retry then |
12:51.58 | 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. |
12:52.00 | radekp | mrmoku: maybe you could load the module which needs firmware when FSO is started |
12:52.19 | radekp | mrmoku: and fso can then supply the fw |
12:52.21 | JaMa | GNUtoo: it's in meta-openmoko right? |
12:52.35 | radekp | mrmoku: instead of making FSO start sooner, you can load the module later :) |
12:52.44 | mickey_office | well |
12:52.56 | mickey_office | given that FSO on some platforms perform quite critical things, starting fsodeviced at least soon is a good idea |
12:53.01 | mickey_office | (think battery chargingĀ
.) |
12:53.12 | GNUtoo | yes |
12:56.49 | mickey_office | then again, i can offer you another alternative |
12:56.56 | mickey_office | we create fsosystemd |
12:57.03 | mrmoku | :) |
12:57.04 | mickey_office | and put all the non-dbus system service plugins in there |
12:57.08 | mickey_office | like charging |
12:57.10 | mickey_office | firmware loading |
12:57.11 | mickey_office | and what not |
12:57.19 | mrmoku | init too? |
12:57.23 | mickey_office | i think that would be a clean solution |
12:57.27 | mickey_office | ya, why not, it would belong there |
12:57.51 | mrmoku | how much work is it? |
12:57.58 | morphis | mickey_office: state of master branch regarding vala is ok, everything should work back again |
12:58.15 | morphis | mickey_office: we had some problems with the changed behaviour of supplying structs as parameters |
12:58.28 | morphis | which does not lead to compilation error but to runtime errors |
12:58.31 | morphis | that is fixed |
12:58.38 | mickey_office | well, the init stuff is a more complex task, but we could start with the other things, that would be easy |
12:58.53 | morphis | 0.14.1 does not include the fixes we need |
12:59.18 | morphis | I already talked to luca bruno about getting my fixes into 0.14.2 and he is reviewing my changes |
12:59.20 | mickey_office | morphis: hmm, so you merged the 014-support to cornucopia-master? |
12:59.33 | morphis | after the problems were gone, yes |
12:59.38 | mickey_office | hmm |
12:59.39 | mickey_office | ok |
12:59.45 | morphis | master is usable now with 0.14.1.7-.... |
12:59.50 | mickey_office | that means i must fix / revert |
12:59.55 | mickey_office | the things that i don't like |
13:00.02 | morphis | which is here http://downloads.freesmartphone.org/vala-0.14.1.7-3673f.tar.bz2 |
13:00.08 | morphis | yes |
13:00.51 | mickey_office | hmm, ok |
13:01.32 | morphis | I pulled playya__ mdbus2 gbus porting patches in |
13:01.36 | morphis | after some testing and fixes |
13:02.51 | 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 |
13:03.20 | morphis | mickey_office: but please fix the things you don't like |
13:03.42 | radekp | mrmoku: btw do you remember why SHR dropped udev? |
13:03.45 | 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 |
13:04.01 | JaMa | radekp: it was much slower then devtmpfs is |
13:04.14 | mickey_office | radekp: because it's slow and cumbersome and eats kittens. and devtempfs is almost a full substitute for it |
13:04.20 | JaMa | radekp: see bootcharts http://build.shr-project.org/tests/jama/ |
13:04.44 | radekp | i think the problem with udev is that it touches all the uevent files on startup |
13:05.06 | radekp | which is slow, but if this could be disabled, then it could be ok |
13:06.19 | 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 |
13:07.22 | radekp | otherwise udevd should be quite lightweight - it's written in pure C, it has 120kb here |
13:07.43 | JaMa | it's much better with systemd |
13:07.58 | radekp | if i run udevd from command line it's up instantly |
13:08.40 | radekp | it starts in 1ms |
13:10.49 | *** join/#openmoko-cdevel dos1|N900 (~dos@unaffiliated/dos1) |
13:11.05 | 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 |
13:11.25 | dos1|N900 | JaMa, mrmoku: ping |
13:11.42 | dos1|N900 | we'll need some option to be set in apache conf for our vhost |
13:12.08 | dos1|N900 | IndexOptions +SuppressHTMLPreamble |
13:12.28 | mrmoku | mickey_office: ok, maybe I take a look |
13:12.40 | mrmoku | dos1|N900: pong |
13:13.10 | dos1|N900 | i would set it in .htaccess, but its parsing is disabled |
13:13.14 | mickey_office | mrmoku: cool. it would help me if you just create the daemon and move the plugins from fsodeviced to fsosystemd |
13:13.15 | mrmoku | dos1|N900: is that a option that can be set via .htaccess? |
13:13.32 | mickey_office | mrmoku: i'm still interested to work on the init system |
13:13.35 | mrmoku | mickey_office: yeah... that should be inside my skills :P |
13:13.37 | mickey_office | :) |
13:13.38 | dos1|N900 | mrmoku: ^^ |
13:13.48 | mrmoku | dos1|N900: ok |
13:14.23 | mrmoku | dos1|N900: would we prefer turning on .htaccess parsing? |
13:14.45 | mrmoku | or just get that IndexOptions in the conf |
13:14.47 | dos1|N900 | it's not critical, but you can see on your own what mess is in html code of my page |
13:15.08 | dos1|N900 | mrmoku: turning on .htaccess would be much more flexible for us in the future :D |
13:15.55 | mrmoku | ok |
13:16.28 | mrmoku | has to do a longer daywork phone call first and will then see to get some bearstech contact |
13:16.38 | dos1|N900 | ok, thx |
13:17.02 | dos1|N900 | (.htaccess is already on its place, patiently waiting to be respected :)) |
13:17.08 | mrmoku | :) |
13:22.15 | 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 |
13:25.55 | morphis | mrmoku: there is already the fsoinitd which you can use as base for fsosystemd |
13:26.13 | mrmoku | morphis: yeah, will mix it alltogether :) |
13:26.23 | morphis | but disable the init part :) |
13:26.30 | mrmoku | sure :P |
13:29.08 | mrmoku | dos1|N900: is enabled now |
13:35.01 | mrmoku | radekp: btw. regarding charging on gta04... you have twl4030_charger.allow_usb=1 in your cmdline? |
13:48.52 | GNUtoo | GarthPS, please paste the full command |
13:49.02 | GNUtoo | s/command/line |
13:49.13 | GNUtoo | (the @base_conditional |
13:49.14 | GNUtoo | ) |
13:50.11 | GarthPS | GNUtoo: DEPENDS = "libfribidi libtool libgcrypt gst-plugins-bad virtual/libsdl qt4-x11-free dbus libxml2 gnutls tremor faad2 ffmpeg flac \ |
13:50.11 | GarthPS | " |
13:50.11 | GarthPS | # ${@base_conditional('ENTERPRISE_DISTRO', '1', '', 'libmad libid3tag liba52 mpeg2dec', d)}" |
13:50.38 | GNUtoo | GarthPS, if entreprise distro is 1 then add '' as dependences, else add 'libmad etc....' |
13:50.42 | GNUtoo | that's what it does |
13:50.56 | GNUtoo | and there is a comment before also |
13:50.59 | GNUtoo | so remove the comment |
13:51.08 | GarthPS | So for me right now vlc_1.1.11 is broken as it does not build if you don't build libmad before |
13:51.11 | GNUtoo | but it'll surely fail with lacking recipes |
13:51.17 | GNUtoo | yes |
13:51.24 | GNUtoo | GarthPS, what about mplayer? |
13:52.25 | GarthPS | GNUtoo: why it is commented ? mplayer did not tried yet |
13:52.49 | GNUtoo | because I guess that some recipes were not in core based oe at the time |
13:53.16 | GNUtoo | some of the dependencies like libmmad etc... |
13:53.32 | GNUtoo | GarthPS, oe-core still lacks a lot of recipes |
13:53.49 | GarthPS | GNUtoo: well libmad is there now |
13:53.53 | GNUtoo | and I really don't have the time to add them back |
13:54.07 | GNUtoo | yes so try uncommenting that line and see what's still lacking |
13:54.15 | GarthPS | GNUtoo: I will tell you if the comment can be removed |
13:54.25 | GarthPS | trying to build vlc right now |
13:54.31 | GNUtoo | if so send a patch |
13:54.40 | GNUtoo | or push if you have push access |
13:56.00 | GarthPS | GNUtoo: ok I will (don't have right access) |
13:56.08 | GNUtoo | ok |
13:56.09 | GarthPS | or write access :) |
13:56.15 | GNUtoo | ok |
13:58.18 | JaMa | GarthPS: please send it directly to OE-devel ML as written in README of meta-oe layer ;) |
13:58.41 | radekp | mrmoku: is that needed? |
13:59.57 | JaMa | GarthPS: also read this thread http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-September/034954.html |
14:00.42 | mrmoku | radekp: yup, with 3.x it is needed to enable charging |
14:00.52 | mrmoku | did not try the wall charger as I can't find it :P |
14:01.04 | mrmoku | but for charging via usb I need that |
14:01.51 | radekp | mrmoku: cool thanks, i'll try |
14:01.56 | mrmoku | yw |
14:16.44 | dos1|N900 | mrmoku: great, thanks :) |
14:16.52 | dos1|N900 | it works \o/ |
14:32.58 | *** join/#openmoko-cdevel anarsoul (~anarsoul@86.57.155.118) |
14:38.19 | mrmoku | dos1|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.26 | angelox|laptop | dos1: wow, fantastic working site :) |
15:56.49 | dos1 | i've flashed shr-aurora on gta02 |
15:57.00 | dos1 | how to turn off the device correctly? xD |
15:57.11 | angelox|laptop | wopps we forgot that part :) |
15:57.59 | angelox|laptop | when i had my n900 i turned off using ssh :) |
15:58.55 | mrmoku | dos1: just use the battery switch ;) |
16:15.14 | Ainulindale | aurora ? |
16:15.16 | Ainulindale | what's that? |
16:22.02 | mrmoku | Ainulindale: framebuffer, qt based feature phone flavour |
16:22.19 | mrmoku | mainly 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.08 | angelox|laptop | wow, morphis was there and i did not see :) |
16:27.22 | angelox|laptop | morphis: http://wiki.freesmartphone.org/index.php/Aurora/Screenshots |
16:30.08 | mrmoku | root@om-gta04:~# opkg install fsosystemd |
16:30.08 | mrmoku | Installing fsosystemd (0.0.1+gitr1+20a9ce696d738036c41298a1e185696cc701ec8f-r6.0) to root... |
16:30.11 | mrmoku | Downloading http://ladyt/shr-core/ipk//armv7a-vfp-neon/fsosystemd_0.0.1+gitr1+20a9ce696d738036c41298a1e185696cc701ec8f-r6.0_armv7a-vfp-neon.ipk. |
16:30.14 | mrmoku | Configuring fsosystemd. |
16:36.11 | angelox|laptop | Successfully? :) |
16:39.07 | GNUtoo | what's fsosystemd? |
16:40.04 | *** join/#openmoko-cdevel pespin (~pespin@254.Red-88-28-136.staticIP.rima-tde.net) |
16:40.07 | GNUtoo | I don't see it in cornucopia |
16:40.09 | GNUtoo | pespin, hi |
16:40.43 | dos1 | ok, i've played a bit with aurora on gta02 |
16:40.52 | pespin | hi! finally I have conn from a mobile's friend sharing it hehe |
16:40.55 | dos1 | now flashing shr-shr :D |
16:40.55 | GNUtoo | dos1, how is it? |
16:41.13 | dos1 | GNUtoo: awfuuuuuuuullyyyy sloooooooooooow |
16:41.20 | GNUtoo | ah ok |
16:41.34 | dos1 | GNUtoo: and nonuseable anyway :D there's something wrong with telephony |
16:41.44 | GNUtoo | ah again? |
16:41.58 | GNUtoo | maybe something is wrong |
16:42.05 | GNUtoo | last time I looked it was not that slow |
16:42.07 | dos1 | outgoing call was displayed as incoming |
16:42.10 | GNUtoo | but it was unusable the same |
16:42.11 | GNUtoo | ok |
16:42.27 | dos1 | truly incoming call couldn't be rejected nor accepted |
16:43.24 | GNUtoo | dos1, when was the build from? |
16:43.36 | mrmoku | GNUtoo: have to push it |
16:43.45 | GNUtoo | ok |
16:43.46 | mrmoku | GNUtoo: it will solve the firmware loading problem |
16:43.49 | mrmoku | as a first step |
16:44.04 | GNUtoo | ah? but we have fsodeviced for that |
16:44.07 | dos1 | GNUtoo: 004 |
16:44.12 | GNUtoo | with firmware loader |
16:44.15 | GNUtoo | dos1, ok |
16:44.21 | mrmoku | GNUtoo: yeah, but the problem with that is a hen - egg one |
16:44.23 | dos1 | added report to wiki |
16:44.31 | mrmoku | fsodeviced might need a module for a plugin |
16:44.38 | mrmoku | and modules need fsodeviced as firmware loader |
16:44.59 | GNUtoo | ok |
16:45.55 | mrmoku | GNUtoo: all essential and basic low-level device stuff that does not need dbus should go there |
16:46.07 | mrmoku | like the n900 charging plugin too |
16:46.08 | GNUtoo | ok |
16:48.45 | antrik | GNUtoo: I'm still using u-boot on GTA02. not sure where I got it from though... probably not SHR |
16:50.05 | GNUtoo | ok |
16:53.52 | morphis | mrmoku: no, it's not framebuffer restricted and currently we're using x11 |
16:55.46 | mrmoku | morphis: ohh... didn't know that |
16:55.50 | mrmoku | Ainulindale: ^^ |
16:55.56 | morphis | mrmoku: no problem |
16:56.11 | morphis | mrmoku, Ainulindale: so Aurora is SHR without E17 UI but with Qt based UI |
16:56.18 | mrmoku | morphis: I have a fsosystemd now |
16:56.33 | mrmoku | I'm wondering about what plugins can move there though |
16:57.03 | mrmoku | the n900 charging plugin has a comment // internal (accessible for aggregate power supply) |
16:57.17 | mrmoku | which tells me it can't go to fsosystemd probably |
16:57.42 | mrmoku | <PROTECTED> |
16:57.44 | morphis | mrmoku: whats the general idea about fsosystemd? |
16:57.45 | mrmoku | yeah |
16:57.59 | morphis | I thought it should be carry only system stuff and not device things |
16:58.10 | morphis | like firmware handling |
16:58.11 | mrmoku | first step to have the essential critical stuff |
16:58.13 | mrmoku | yeah |
16:58.19 | mrmoku | there's not much to go there |
16:58.25 | mrmoku | charging would have been a nice one though |
16:58.30 | morphis | really? |
16:58.34 | mrmoku | the earlier we can charge the better |
16:58.39 | morphis | hm |
16:58.53 | morphis | we have the power supply dbus API |
16:58.55 | mrmoku | anyway... will just push it with the firmware loader |
16:58.59 | morphis | ok |
16:59.07 | mrmoku | yeah, but you can't enable/disable charging there |
16:59.16 | morphis | I thing fsosystemd should carry only some little system stuff |
16:59.33 | morphis | yes |
16:59.40 | morphis | thats some feature we should really implement |
16:59.52 | mrmoku | enable disable charging? |
16:59.53 | mrmoku | why that |
17:00.16 | morphis | for example: you're in the train, laptop battery is low |
17:00.28 | morphis | and you connect your phone to have internet access via usb |
17:00.39 | morphis | then the phone should not charge over USB |
17:00.49 | mrmoku | hmm |
17:00.55 | mrmoku | that would be a usecase |
17:01.01 | morphis | but it's not really important :) |
17:01.05 | mrmoku | no :P |
17:01.08 | morphis | we have more important use cases |
17:01.18 | morphis | ok, so we have a fsosystemd now |
17:01.29 | morphis | do you converted the fsoinitd to be plugin-based? |
17:01.54 | morphis | hm I dropped fsoinitd some time ago ... |
17:02.08 | mrmoku | well in the end it's taken more from fsodeviced |
17:02.27 | mrmoku | when I saw fsoinitd has no plugin stuff :) |
17:02.35 | morphis | ok |
17:02.54 | morphis | but I am not sure wether fsosystemd should provide a dbus API |
17:03.32 | mrmoku | no it can't |
17:03.45 | mrmoku | well it could, but not on startup |
17:04.11 | mrmoku | dbus starts way too late |
17:04.29 | morphis | yes |
17:04.52 | morphis | btw. I started to implement a test suite for our dbus API |
17:05.09 | morphis | which you can run and you have a report at the end which stuff works as it should and which not |
17:05.27 | mrmoku | nice |
17:05.40 | morphis | would also help to adjust different implementations like in the GSM domain |
17:05.42 | morphis | yes |
17:06.01 | morphis | it's something we really need even with the aim to get a stable distribution |
17:06.30 | dos1 | JaMa: shr-full-om-gta02.ubi from 004 does not mount |
17:07.03 | dos1 | JaMa: UBI error: process_eb: bad image sequence number 1880304218 in PEB 1969, expected 1537023111 |
17:07.27 | dos1 | downloading lite now |
17:07.34 | dos1 | (btw. aurora ubi image worked) |
17:07.52 | morphis | dos1: aurora in the gta02? |
17:08.00 | dos1 | morphis: yup |
17:08.10 | morphis | does it startup the UI? |
17:08.19 | dos1 | yup |
17:08.24 | dos1 | it's awwwfuuulllyyyy sloooooow |
17:08.29 | dos1 | and has problems with telephony |
17:08.36 | dos1 | but it starts and somehow works |
17:10.47 | mrmoku | dinner |
17:11.38 | morphis | dos1: :) |
17:12.11 | morphis | yes latest version (004) has problems with telephony but they are fixed and 005 should be working |
17:12.38 | JaMa | morphis: ? |
17:12.39 | angelox|laptop | morphis: should it be so slow? |
17:14.37 | angelox|laptop | morphis: and that is cpp version? |
17:16.11 | GNUtoo | pespin, hi did I say that I fixed mplayer for ogg vorbis on om-gta02? |
17:16.41 | pespin | GNUtoo, nop, I didn't know |
17:16.47 | pespin | GNUtoo, mplayer2 or 1? |
17:16.53 | dos1 | JaMa: the same problem with lite :( |
17:16.54 | pespin | 2 right? |
17:16.56 | GNUtoo | both I guess |
17:17.02 | GNUtoo | the fix is in mplayer-config |
17:17.08 | GNUtoo | so I tried with mplayer2 |
17:17.12 | GNUtoo | but maybe it fixes 1 too |
17:17.17 | pespin | GNUtoo, hmm wait, wasn't your problem with gstreamer? |
17:17.26 | GNUtoo | I've many problems..... |
17:17.29 | pespin | getting noise instead of music |
17:17.31 | pespin | lol |
17:17.50 | GNUtoo | one of the problem is mplayer not playing well ogg vorbis => fixed in git |
17:17.58 | pespin | GNUtoo, buy an ukelele, I did it some days before and it helps to follow the happiness path ;) |
17:18.05 | GNUtoo | other problems include n900 not working well for instance |
17:18.11 | GNUtoo | lol |
17:18.27 | JaMa | dos1: did you use dfu-util or cleaned and flashed from uSD? |
17:18.36 | dos1 | JaMa: dfu-util |
17:18.58 | JaMa | pespin: can you please apply the BINDINGS/vala patch to fix label_set _before_ the big merge with API from your 2nd repo? |
17:19.25 | dos1 | flashing aurora worked, flashing shr-lite or shr-full didn't |
17:19.28 | GNUtoo | pespin, or maybe I should write a jamendo app for the om-gta02 |
17:19.34 | pespin | JaMa, apply it in E svn? |
17:19.38 | JaMa | pespin: yes |
17:19.48 | pespin | JaMa, do you have patch at hand? |
17:20.00 | pespin | as I modified it to apply for newer eflvala |
17:20.05 | JaMa | pespin: so we will be able to stay with some E svn SRCREV (without extra patch) until all apps are fixed |
17:20.27 | pespin | ok |
17:20.41 | 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 |
17:21.07 | morphis | JaMa: I think 005 will be the next staging version and it includes my latest commit for meta-smartphone which bumps aurora SRCREV |
17:21.20 | pespin | GNUtoo, I haven't played with jamendo yey, is it good? |
17:21.20 | morphis | angelox|laptop: it's the graphic stuff which is so slow on the om-gta02 |
17:21.34 | GNUtoo | pespin, very, I've a jamendo app on replicant |
17:21.43 | JaMa | morphis: 004 will have it (it wasn't closed yet) |
17:21.46 | GNUtoo | (the music is very good) |
17:21.48 | *** join/#openmoko-cdevel anarsoul (~anarsoul@212.98.189.25) |
17:21.57 | angelox|laptop | morphis: ah ok |
17:22.00 | JaMa | morphis: and I'm rebuilding those images atm, because of dbus issue |
17:22.08 | morphis | ah ok |
17:22.11 | morphis | then it will be 004 |
17:22.29 | pespin | GNUtoo, only free music right? |
17:22.44 | GNUtoo | freely redistributable yes |
17:22.52 | JaMa | actualy I've removed oll older images for armv7 because they all had wrong dbus owner :/ |
17:22.58 | GNUtoo | creative commons and some other licenses |
17:23.13 | GNUtoo | but as you know CC have stuff like ND NC etc.... |
17:23.29 | GNUtoo | but redistributable is good enough for me |
17:23.42 | pespin | nice |
17:23.52 | pespin | GNUtoo, lots of classical music I guess? |
17:24.04 | GNUtoo | there is some classical |
17:24.11 | GNUtoo | not only classical |
17:24.23 | GNUtoo | for classical there is also another website |
17:24.29 | pespin | I guess most of classical music is under public domain right now right? |
17:24.31 | GNUtoo | musopen |
17:24.34 | GNUtoo | yes |
17:24.43 | GNUtoo | but jamendo has everything, not only classical |
17:24.45 | pespin | ok :) |
17:24.59 | pespin | does it have some kinf of API or webservice? |
17:25.31 | GNUtoo | yes it does |
17:25.40 | GNUtoo | else the jamendo app wouldn't work |
17:25.54 | GNUtoo | also there is jamendo integrated in many desktop clients |
17:25.56 | GNUtoo | like totem |
17:26.01 | GNUtoo | or rythmbox |
17:26.38 | 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?... |
17:26.59 | JaMa | antrik: like wht? |
17:27.09 | GNUtoo | basically on jamendo you won't find a lot of interpretation of classical music but rather new songs including classical ones |
17:27.32 | GNUtoo | (for interpretation of classical stuff there is wikipedia, musopen etc...) |
17:27.35 | pespin | nice, I'd give a try but I have enough stuff to do with emtooth2 and etalk and all this eflvala shit. |
17:27.40 | GNUtoo | ok |
17:27.51 | GNUtoo | maybe just listen to the music in a desktop client then |
17:28.06 | pespin | yeah :) |
17:29.11 | JaMa | going home, bbl |
17:32.33 | *** join/#openmoko-cdevel NIN101 (~NIN101@2001:530::216:3cff:fe71:5e1e) |
17:43.09 | pespin | JaMa, I had to hack manually my Elementary.h as I don't have here in netbook such new elementary. |
17:43.22 | pespin | apart from that looks ok, I'll push |
17:43.46 | JaMa | good, one less efl patch in meta-efl :) |
17:44.00 | antrik | pespin: new recordings of classical music are not at all public domain |
17:44.34 | antrik | in fact, considering the time when recordings became common, you will be hard pressed to finde *any* that are public domain... |
17:44.38 | pespin | antrik, so the copyright is per recording, not per piece? |
17:45.10 | antrik | JaMa: you were talking about ffphonelog and ffalarms |
17:45.47 | JaMa | antrik: and did I say I have removed them? |
17:46.11 | pespin | JaMa, Committed revision 65990. |
17:46.22 | JaMa | pespin: thx |
17:47.43 | antrik | pespin: the copyright is on a lot of things; including original composition, arrangement, performance, and even the actual recording I think... |
17:48.21 | pespin | ugh what a mess then |
17:48.27 | antrik | indeed |
17:48.27 | Ainulindale | Hmmm well for the aurora thingy |
17:48.42 | Ainulindale | Why not evolve on the SHR stack basis? |
17:48.52 | Ainulindale | (and/or fork and/or ditch the current one) |
17:49.14 | Ainulindale | (this isn't a trick question) |
17:49.48 | Ainulindale | Because at the beginning of SHR the goal was (and hopefully ever is) to do exactly that :-) |
17:49.59 | antrik | JaMa: no, but you said that you can drop them instead of adapting for newer eflvala... |
17:51.30 | JaMa | antrik: I've said that about apps nobody cares about |
17:52.02 | 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.. |
17:52.07 | antrik | Ainulindale: the official justification is that the SHR stack is supposedly to complex for testing FSO |
17:52.22 | JaMa | antrik: and I plan to do it again if needed just to be able to use newer EFL if possible |
17:52.36 | Ainulindale | I don't care about the stack we're talking about testing features |
17:52.52 | Ainulindale | SHR is mainly a distribution with no concern for specific stacks |
17:53.08 | Ainulindale | So if the purpose is to test all the features |
17:53.19 | antrik | JaMa: well, obviously anyone actually wanting to use it for a phone will care at least about ffphonelog... |
17:53.23 | Ainulindale | Then 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.49 | JaMa | antrik: there there is no issue and I don't understand why you said I plan to remove it |
17:53.58 | Ainulindale | That is : sensible, usable and coherent UI for phone functionnalities and settings |
17:54.01 | JaMa | s/there there/then there/ |
17:57.02 | antrik | JaMa: well, maybe I misread your statement. it sounded like you considered it a serious option |
17:57.10 | 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) |
17:57.15 | antrik | 19:17 < JaMa> pespin: those apps are pretty simple |
17:57.16 | antrik | 19:17 < JaMa> pespin: so if someone still cares they can be fixed even with little more help then easy sed commands |
17:57.19 | antrik | 19:18 < JaMa> and if nobody cares then we'll just drop them from feed :) |
17:57.56 | antrik | I didn't say you *plan* to remove them... I asked whether you are seriously considering it |
17:58.50 | antrik | Ainulindale: I'm not sure what you are trying to say... |
17:59.02 | Ainulindale | I'm not trying to say something, I'm saying it :-) |
17:59.37 | mrmoku | :) |
17:59.46 | 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? |
17:59.51 | Ainulindale | Is there a specific reasons which would explain that? |
17:59.52 | CIA-82 | freesmartphone.org: 03mok 07cornucopia * r341524bc4241 10/fsosystemd/ (20 files in 7 dirs): |
17:59.52 | CIA-82 | freesmartphone.org: fsosystemd: initial implementation |
17:59.52 | CIA-82 | freesmartphone.org: Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de> |
18:00.20 | mrmoku | the problem seems to be the complexity of the SHR phone stack |
18:00.24 | 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...) |
18:00.33 | *** join/#openmoko-cdevel Slyon (~lukas@ppp-93-104-23-249.dynamic.mnet-online.de) |
18:00.39 | Slyon | hey |
18:00.43 | mrmoku | yo Slyon |
18:00.46 | morphis | Ainulindale: it's not a fork |
18:00.59 | morphis | Ainulindale: it's just a playground for me and mickeyl |
18:01.04 | Ainulindale | mrmoku: What about the "complexity of the SHR phone stack"? |
18:01.17 | Ainulindale | Because this expression sounds to me as a "me don't like C me do other stuff" |
18:01.26 | mrmoku | :) |
18:01.32 | Ainulindale | Just trying to find out the goal or purpose behind that |
18:01.34 | mrmoku | I'm not the right one to talk with here :P |
18:01.39 | Ainulindale | mrmoku: meh |
18:01.43 | Ainulindale | mrmoku: you suck! :-) |
18:01.48 | mrmoku | likes C ;) |
18:01.55 | 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? |
18:01.56 | Ainulindale | morphis: well then please enlighten me :-) |
18:02.03 | Ainulindale | (bad pun sorry) |
18:02.10 | Ainulindale | :-> |
18:02.23 | mrmoku | Slyon: uhh |
18:02.24 | Ainulindale | mrmoku: C is for men! |
18:02.27 | mrmoku | not without looking |
18:02.27 | morphis | Ainulindale: in general mickeyl and I wanted a very tiny stack to play with FSO and Qt Quick |
18:02.36 | Ainulindale | mrmoku: With a nice heavy pair... of coffee pots! |
18:02.42 | morphis | with not much stuff in the stack |
18:02.48 | mrmoku | and some beer in between :) |
18:02.51 | Ainulindale | morphis: What's "not much stuff" ? |
18:02.57 | Ainulindale | Because if in the end you implement all the features |
18:03.02 | Ainulindale | I'd say there'll be more stuff |
18:03.03 | Slyon | mrmoku, you did it in modem_option_gtm601 while overwriting +COPS |
18:03.05 | morphis | complete X11 with a lot of daemons and applications |
18:03.13 | mrmoku | Slyon: yeah, but my memory sucks a lot :P |
18:03.21 | Ainulindale | morphis: Well then isn't it the goal of the distro and not the stack? |
18:03.29 | GNUtoo | Ainulindale, C is a nice high level programming language |
18:03.45 | Ainulindale | What prevented you from using the current stack although stirpped down to the bare needed daemons? |
18:04.26 | Ainulindale | Please note that I'm not saying it's a bad idea or criticizing there |
18:04.34 | Ainulindale | Just trying to have an understanding of the reason |
18:04.58 | Ainulindale | Because 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.59 | mrmoku | Slyon: match = tere.match( response, 0, out mi ); |
18:06.15 | mrmoku | probably te = Terminal Equipment |
18:06.37 | Slyon | mrmoku, so tere = response from modem |
18:06.38 | morphis | Ainulindale: first it's not another distro |
18:06.45 | morphis | Ainulindale: it's SHR with another UI |
18:07.00 | morphis | Ainulindale: mickeyl and I was impressed by the power you have with Qt Quick |
18:07.20 | mrmoku | Slyon: yeah, regex that should match the modem's response |
18:07.32 | Ainulindale | well do you really feel it's worth time and effort to build yet another UI morphis? |
18:07.38 | morphis | Ainulindale: an we wanted a better replacement for zhone2 |
18:07.50 | morphis | Ainulindale: yes and no |
18:08.05 | morphis | Ainulindale: you are right it's much time we need to get it working |
18:08.10 | Slyon | mrmoku, that makes it easy, as AT+CHUP shouldn't give any response |
18:08.53 | morphis | Ainulindale: but in detail you are really was with Qt Quick to implement new applications and features |
18:09.21 | Ainulindale | morphis: I didn't understand this last sentence |
18:09.46 | morphis | s/need/needed/ |
18:10.05 | mrmoku | Slyon: hehe, yeah |
18:10.29 | Ainulindale | morphis: I didn't understand the last sentence, not the penultimate :-) |
18:10.44 | morphis | Ainulindale: let's not continue this discussion right now as I run out of time |
18:11.07 | morphis | Ainulindale: but in detail you are really fast with Qt Quick to implement new applications and features |
18:11.16 | morphis | thats the correct sentence |
18:11.22 | morphis | sorry for that |
18:11.26 | Ainulindale | no problem |
18:11.32 | *** join/#openmoko-cdevel toams (~tommi@94-224-20-159.access.telenet.be) |
18:11.39 | morphis | Ainulindale: don't give the Aurora project too much importance |
18:11.47 | morphis | the focus of the community is still at the SHR UI |
18:11.53 | morphis | and thats ok and good |
18:11.53 | JaMa | antrik: ok, then we both misunderstood each other a bit.. |
18:12.00 | Ainulindale | morphis: well |
18:12.07 | Ainulindale | morphis: the SHR ui was crap when I stopped working on SHR |
18:12.12 | Ainulindale | morphis: so I don't care about that :-) |
18:12.24 | Ainulindale | I'm just trying to have a good vision of what's done and what'll be interesting |
18:12.35 | morphis | ok |
18:12.47 | morphis | then we should talk again when I have more time |
18:12.49 | angelox|laptop | morphis: please, when you have time, check the about app i did create :D |
18:13.04 | morphis | angelox|laptop: which one? |
18:13.21 | angelox|laptop | in settings-rework app-about my three last commits |
18:13.30 | morphis | angelox|laptop: ok |
18:13.38 | angelox|laptop | there's an inma in aurora's screenshots page |
18:13.40 | 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 :) |
18:13.43 | angelox|laptop | s/inma/image/ |
18:14.32 | mrmoku | JaMa: there is started phonelog integrated in libphone-ui-shr... would just have to finish it :P |
18:14.39 | morphis | Ainulindale: so you are back to the project now? |
18:14.50 | Ainulindale | Certainly not |
18:15.07 | Ainulindale | I don't have neither time or frame of mind for it :-) |
18:15.11 | morphis | ok |
18:15.12 | Ainulindale | Do unit tests, do QA |
18:15.17 | Ainulindale | Then maybe I'll come back |
18:15.20 | morphis | :) |
18:15.21 | Ainulindale | Meanwhile, NO GO :-) |
18:15.23 | JaMa | mrmoku: hehe, if pespin is right then maybe it will be easier to finish it then converting ffphonelog to new eflvala API :) |
18:15.29 | mrmoku | Ainulindale: but you will certainly participate in the release part - whenever that is, right? :) |
18:15.47 | Ainulindale | Well if we're still alive by then, sure |
18:15.51 | JaMa | mrmoku: but Lukas is still sending patches for ff* so I belive he will fix it himself |
18:15.56 | Ainulindale | :-p |
18:15.59 | mrmoku | :P |
18:16.13 | Ainulindale | mrmoku: but you know how it is |
18:16.20 | Ainulindale | If there is no clear direction/leadership |
18:16.23 | Ainulindale | with one firm goal |
18:16.32 | Ainulindale | And if everybody does its thing by itself |
18:16.41 | Ainulindale | It won't amount to much sadly because it won't have any coherence |
18:16.46 | JaMa | mrmoku is respected and beloved leader! :) |
18:17.06 | Ainulindale | (Not saying that it's bad that there are other initiatives there, only that it kills planification) |
18:17.32 | JaMa | and he will also buy me nice BMW on our way to Essen I belive :) |
18:17.43 | mrmoku | never felt like being the leader... probably a wrong thing |
18:18.07 | antrik | JaMa: I see. misunderstanding indeed :-) |
18:18.14 | morphis | we have no one who is in the positon of a leader |
18:18.27 | mrmoku | Ainulindale: that's all stuff we will discuss soon in a very nice location :) |
18:18.30 | morphis | just a lot of people with a lot of thing to do :) |
18:18.44 | mrmoku | Ainulindale: to get a plan |
18:18.59 | Ainulindale | well |
18:19.04 | Ainulindale | talking is one thing |
18:19.08 | Ainulindale | enforcing it is another one |
18:19.23 | Ainulindale | remember the heated discussion we had when I was still working? :-) |
18:19.29 | Ainulindale | s/ssion/ssions/ |
18:19.52 | mrmoku | the french - french discussions? ... yeah, how could I forget :P |
18:19.56 | Ainulindale | sadly every project needs a leader even though it's not enjoyable nor rewarding |
18:20.13 | Ainulindale | mrmoku: meh ! :-) |
18:20.26 | Ainulindale | By the way I have no news about him (ptitjes) |
18:20.42 | Ainulindale | He moved in the south of france a while back that's all I know |
18:21.05 | mrmoku | I think he showed some signs of activity somewhere... not in here though |
18:21.09 | Ainulindale | vala? |
18:21.16 | mrmoku | libgee I think |
18:21.32 | Ainulindale | Well I hope he'll stop hopping from project to project one day :-) |
18:21.44 | mrmoku | as long as he's happy :) |
18:21.47 | Ainulindale | Yep |
18:21.52 | Ainulindale | I wasn't at the time though |
18:22.00 | Ainulindale | It's hard to say no to someone with ideas |
18:22.06 | Ainulindale | Especially in FLOSS communities |
18:23.33 | GNUtoo | morphis, I've an issue with fsousaged on crespo: |
18:23.34 | GNUtoo | 2011-10-18T02:56:24.611924Z [INFO] fsousaged : received signal -11, shutting down... |
18:23.39 | GNUtoo | continuously |
18:23.40 | GNUtoo | hmmm |
18:23.43 | 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 :-) |
18:23.54 | Ainulindale | mrmoku: so draw your own conclusions from that |
18:24.21 | 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 :-) |
18:24.47 | Ainulindale | well no |
18:24.49 | Ainulindale | that's not a problem |
18:24.50 | GNUtoo | maybe I should try a new iimage? |
18:24.57 | Ainulindale | s/a /the / |
18:24.58 | *** join/#openmoko-cdevel SabotageAndi (~SabotageA@h081217018227.dyn.cm.kabsi.at) |
18:25.19 | 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 |
18:25.31 | Ainulindale | And then you have each and every developer doing his own thing |
18:25.34 | Ainulindale | And no common thing |
18:25.40 | Ainulindale | Hence no coherence, no planning, no deliverable |
18:25.47 | Ainulindale | => no usable phone :-) |
18:26.00 | angelox|laptop | morphis: 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.35 | Ainulindale | mrmoku: but IMHO that's the thin line between a project and a "for free" project |
18:26.43 | Ainulindale | You can't say no but you must say no |
18:27.23 | mrmoku | hmm |
18:27.44 | mrmoku | Ainulindale: what do you mean by "for free" ? |
18:28.52 | Ainulindale | well |
18:28.55 | Ainulindale | you're not paid for SHR |
18:29.02 | Ainulindale | you're doing that because you want to enjoy yourself and build something |
18:29.14 | Ainulindale | so it's hard to be assigned to tasks you don't like |
18:29.20 | Ainulindale | (such as QA, unit testing) |
18:29.22 | *** join/#openmoko-cdevel KaZeR (~kazer@74.43.195.77.rev.sfr.net) |
18:29.23 | Ainulindale | even though it's necessary |
18:29.27 | mrmoku | ahh... difference between some comercial project and one like this one with volunteers |
18:29.30 | mrmoku | yeah |
18:29.32 | Ainulindale | yep |
18:29.45 | 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... |
18:29.47 | mrmoku | indeed yeah |
18:29.48 | Ainulindale | In my case, I didn't like posting in ML and blogs and such and forced myself to |
18:29.51 | Ainulindale | And it was annoying |
18:30.07 | Ainulindale | antrik: well you rephrased what I just said :-) |
18:30.17 | pespin | hmm that remembers me I haven't posted in the shr blog since august lol |
18:30.19 | Ainulindale | antrik: but that's why I created the core team |
18:30.34 | Ainulindale | The core team having the power to talk about stuff, decide, and impose the choice |
18:30.53 | Ainulindale | Because in the end that's what necessary |
18:31.26 | Ainulindale | A group of able and experienced people making choices with one of them being the guy taking the blows |
18:31.34 | Ainulindale | (not the blowjobs, just plain actual blows) |
18:31.45 | Ainulindale | As in every project in fact |
18:31.57 | Ainulindale | (but again, that's only my humble theory) |
18:32.41 | 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 |
18:33.31 | Ainulindale | antrik: the core team is there to have heated discussion to come up with a consensual compromise |
18:33.34 | Ainulindale | then the leader imposes |
18:33.45 | Ainulindale | At least that's what I did when I was the (self-attributed) leader |
18:34.01 | Ainulindale | And it (almost) worked |
18:34.21 | Ainulindale | But my solution is only my solution, I don't pretend it to be the best |
18:35.56 | 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 |
18:36.03 | Ainulindale | A huge mess |
18:36.17 | Ainulindale | (compared to parallel spaghetti that is :-p) |
18:36.45 | mrmoku | you're putting the spaghetti in parallel before eating them? ;) |
18:37.57 | Ainulindale | Obviously yeah I'm insane |
18:38.04 | Ainulindale | (No: I don't eat spaghetti) |
18:38.09 | mrmoku | :P |
18:38.12 | mrmoku | I have too |
18:38.15 | mrmoku | often |
18:38.28 | GNUtoo | /sbin/spa-getty ? |
18:38.34 | Ainulindale | But I'm too fond of logical architectures well thought through and through |
18:39.06 | antrik | heated discussions are possible without a core team ;-) |
18:39.22 | Ainulindale | Yeah but then N > S |
18:39.33 | Ainulindale | and you want to work with people who'll be motivated enough to do the dirty work |
18:39.46 | Ainulindale | in 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.00 | Ainulindale | Been there done that :-) |
18:40.30 | Ainulindale | Because in the end even though you may deliver something not perfect |
18:40.33 | Ainulindale | You'll deliver something |
18:40.45 | Ainulindale | And if it needs modifications, it's never too late anyway (after the release ! :-p) |
18:41.50 | 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 |
18:42.16 | GNUtoo | there are maintainers tough |
18:43.39 | Ainulindale | antrik: there is a leader, there is a kind of "referee" |
18:43.42 | mrmoku | indeed many subsystems all with maintainer(s) and there own mailing list for the heated discussions |
18:43.52 | Ainulindale | antrik: and you're talking kernel which is far more difficult than a mere UI |
18:44.09 | Ainulindale | plus what the other guys said |
18:44.12 | Ainulindale | :-) |
18:44.43 | Ainulindale | antrik: again, not saying I have THE solution there, just trying to explain what I think is difficult in this kind of project |
18:45.09 | antrik | mrmoku: most of the subsystems in turn have a clear leader and no core team |
18:45.37 | Ainulindale | antrik: yeah but in this case it's almost the leader's job |
18:45.54 | Ainulindale | antrik: and having leaders might be problematic (cf. Theo de Raadt) |
18:46.04 | GNUtoo | lol |
18:46.06 | Ainulindale | antrik: the core team is also there to be a buffer in order to prevent egomaniacs |
18:46.30 | 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 |
18:47.28 | Ainulindale | It feels more democratic that way, some kind of collective intelligence |
18:47.47 | Ainulindale | And 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.48 | nschle85 | Ainulindale: what was your problem with developers in shr ? |
18:52.04 | 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 |
18:54.19 | antrik | Ainulindale: I don't really believe in democracy in managing free software projects. it causes endless infighting, and prevents true innovation |
18:54.46 | Ainulindale | antrik: well it wasn't democracy per se |
18:54.54 | Ainulindale | kind of an oligarchy |
18:55.01 | Ainulindale | but with cooptation |
18:55.07 | Ainulindale | anyways I have to eat, be back in a while |
18:55.11 | 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. |
18:55.18 | GNUtoo | again some strlen on NULL strings |
18:55.27 | nschle85 | antrik: or fork :-) |
18:55.48 | GNUtoo | http://www.pastie.org/private/zzl9yydxhht3m9azumeeq |
18:56.07 | antrik | nschle85: right. that's one way of working on another project :-) |
18:56.22 | antrik | (usually preferable to starting from scratch) |
18:57.01 | nschle85 | see Hudson, LibreOffice, XFRee .... |
18:59.33 | Ainulindale | it's not always a good thing |
19:00.41 | GNUtoo | xorg was a good thing |
19:01.03 | nschle85 | GNUtoo: agree but forking often reduces manpower |
19:05.48 | *** join/#openmoko-cdevel ThibG (~ThibG@81-64-18-234.rev.numericable.fr) |
19:06.06 | 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. |
19:06.21 | GNUtoo | depends |
19:06.37 | GNUtoo | in xorg it took the project ahread |
19:06.48 | antrik | many projects actually gained *more* developers by forking and thus getting rid of poor leadership |
19:06.58 | GNUtoo | there was the split(monolithic xorg -> modular xorg) |
19:06.59 | GNUtoo | etc... |
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.39 | GNUtoo | morphis, I've found why it fails but I've no idea how to fix |
20:17.40 | GNUtoo | in: |
20:17.56 | GNUtoo | fsousaged/src/plugins/dbus_service/plugin.vala: |
20:18.23 | GNUtoo | this.system_action( action ); |
20:18.26 | GNUtoo | action can be null |
20:18.37 | GNUtoo | and system_action is a signal |
20:18.46 | GNUtoo | so that creates the trace I shown before |
20:18.49 | GNUtoo | hi mickeyl |
20:19.04 | GNUtoo | I guess that's related to the vala upgrade |
20:21.40 | morphis | GNUtoo: I know this error |
20:22.01 | GNUtoo | ok |
20:22.18 | GNUtoo | can you fix it? or is it me that didn't rebuild or something like that? |
20:22.26 | morphis | you need vala-0.14.7-... from here http://downloads.freesmartphone.org/vala-0.14.1.7-3673f.tar.bz2 |
20:22.37 | morphis | it's already included in OE |
20:22.43 | GNUtoo | ok so I'll rebuild |
20:22.49 | morphis | check if you building with this vala version |
20:23.02 | morphis | if not rebuild vala and then all fso stuff |
20:23.08 | GNUtoo | I think I built with an old vala |
20:23.17 | morphis | yes |
20:23.59 | GNUtoo | thanks a lot |
20:24.05 | morphis | no problem :) |
20:26.10 | morphis | thats my job as FSO developer :) |
20:41.01 | mrmoku | morphis: a FSO developer is what I need now :P |
20:41.19 | mrmoku | morphis: 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.33 | mickeyl | mrmoku: IIRC only those which open a pty, i.e. fsogsmd for some configurations |