| 00:06.15 | CIA-45 | SHR: 03shr-devel 07buildhistory * r6fb6420a966c 10/images/palmpre2/eglibc/ (21 files in 2 dirs): images: Build 201204240119 of shr 20120423 for machine palmpre2 on opmbuild |
| 00:28.03 | *** join/#openmoko-cdevel Alex[sp3dev] (~alexander@85.202.228.18) |
| 00:41.28 | pabs3 | wonders if FSO can protect against stuff like https://lwn.net/Articles/494035/ |
| 00:54.48 | CIA-45 | SHR: 03shr-devel 07buildhistory * r2d4b5de8092f 10/images/crespo/eglibc/ (25 files in 3 dirs): images: Build 201204240207 of shr 20120424 for machine crespo on opmbuild |
| 02:20.58 | *** join/#openmoko-cdevel penghb (~penghb@202.108.130.138) |
| 03:13.28 | *** join/#openmoko-cdevel plotr (~name@unaffiliated/plotr) |
| 05:36.34 | *** join/#openmoko-cdevel erwt (~erwt@122.170.104.85) |
| 05:41.20 | *** join/#openmoko-cdevel lamikr (lamikr@nat/nokia/x-tirewtgfqkifwtrb) |
| 06:07.17 | *** join/#openmoko-cdevel alexxy (~alexxy@gentoo/developer/alexxy) |
| 06:12.15 | *** join/#openmoko-cdevel borillion (~borillion@adsl-99-186-40-130.dsl.pltn13.sbcglobal.net) |
| 06:17.03 | *** part/#openmoko-cdevel borillion (~borillion@adsl-99-186-40-130.dsl.pltn13.sbcglobal.net) |
| 06:17.31 | mrmoku | chooses the caffeine overdose protection technique :-) |
| 06:17.48 | *** join/#openmoko-cdevel radekp (~radek@82.113.39.213) |
| 06:20.07 | JaMa | moin |
| 06:28.39 | *** join/#openmoko-cdevel losinggeneration (~quassel@75-170-158-9.desm.qwest.net) |
| 06:35.04 | mrmoku | moin JaMa |
| 06:35.08 | *** join/#openmoko-cdevel GarthPS (~quassel@2a01:e35:2f5c:e670:8868:be28:a19a:41b1) |
| 06:36.15 | *** join/#openmoko-cdevel snkt (~snkt@122.170.104.85) |
| 06:40.51 | CIA-45 | SHR: 03shr-devel 07buildhistory * r2f443849e5f6 10/packages/ (65 files in 65 dirs): packages: Build 201204240831 of shr 20120424 for machine om-gta02 on opmbuild |
| 06:45.17 | *** join/#openmoko-cdevel jackh (~quassel@220.248.0.154) |
| 06:48.19 | PaulFertser | Good morning, everyone :) |
| 06:49.29 | *** join/#openmoko-cdevel alabd (fxfe@unaffiliated/alabd) |
| 06:51.57 | JaMa | 24 hours to EFL release :) time to prepare recipes |
| 06:55.33 | *** join/#openmoko-cdevel SabotageAndi (~SabotageA@80.245.197.109) |
| 06:58.25 | CIA-45 | SHR: 03Martin.Jansa 07shr-chroot * r47a617b67e4d 10/ (1143 files in 28 dirs): system upgrade |
| 07:00.55 | *** join/#openmoko-cdevel ThibG (~ThibG@spike.sitedethib.com) |
| 07:03.14 | *** join/#openmoko-cdevel lamikr (lamikr@nat/nokia/x-rjgsfeqhmmrygmvf) |
| 07:14.32 | DocScrutinizer | morning |
| 07:14.51 | DocScrutinizer | caffeine OD prot tech? drop the cup? |
| 07:15.40 | mrmoku | DocScrutinizer: the lwn article pabs3 posted... one comment suggests caffeine overdose as protection |
| 07:16.54 | *** join/#openmoko-cdevel morphis (~morphis@hfw-ext-wlan.rz.hs-bremen.de) |
| 07:18.39 | DocScrutinizer | awesome |
| 07:22.34 | *** join/#openmoko-cdevel ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 07:22.44 | radekp | JaMa: hi, how long is SHR using systemd? Is it possible that the image i have (from 2012/03/15) is without systemd? |
| 07:26.12 | mrmoku | radekp: yeah, that should have been without systemd |
| 07:26.13 | CIA-45 | SHR: 03shr-devel 07buildhistory * rb9a594ca0af8 10/packages/ (73 files in 73 dirs): packages: Build 201204240857 of shr 20120424 for machine om-gta02 on opmbuild |
| 07:26.22 | mrmoku | the switch was not long ago |
| 07:26.47 | radekp | ahh oki, maybe systemd is more strict about rootfs remounting |
| 07:28.19 | radekp | btw is boot with systemd faster now? |
| 07:28.41 | mrmoku | radekp: 041 had the systemd merge... which was merged to public feed on 3rd April |
| 07:29.38 | mrmoku | if it's faster? no idea yet... guess we still have to iron out some bugs and wait for the dust to settle down :-P |
| 07:30.39 | *** join/#openmoko-cdevel rines (~rnespitha@mnch-4d046107.pool.mediaWays.net) |
| 07:31.25 | radekp | mrmoku: oki, thanks, i am now trying it :) |
| 07:31.41 | mrmoku | yw and have fun :-) |
| 07:35.59 | *** join/#openmoko-cdevel morphis (~morphis@hfw-ext-wlan.rz.hs-bremen.de) |
| 07:41.45 | morphis | JaMa: ping |
| 07:44.22 | *** join/#openmoko-cdevel DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 07:48.37 | DocScrutinizer | *sigh* |
| 07:48.44 | DocScrutinizer | but it's *new* |
| 07:48.49 | DocScrutinizer | ;-P |
| 07:52.54 | JaMa | morphis: pong |
| 07:54.13 | morphis | JaMa: we have a problem with the systemd-machine-units for the Nexus S |
| 07:54.24 | morphis | JaMa: the service files are not packaged |
| 07:54.48 | morphis | and I don't know how to integrate them the right way |
| 07:56.58 | JaMa | looks like multiple entries in SYSTEMD_SERVICE don't realy work |
| 07:57.24 | morphis | no, one entry doesn't work too |
| 07:58.26 | morphis | I also tried with just using SYSTEMD_SERVICE = "..." instead of SYSTEMD_SERVICE_crespo = "..." |
| 07:59.59 | JaMa | will try on buildhost after it finishes build |
| 08:00.35 | morphis | ok |
| 08:01.01 | CIA-45 | SHR: 03shr-devel 07buildhistory * r69a20dc61ddc 10/packages/ (73 files in 73 dirs): packages: Build 201204240933 of shr 20120424 for machine nokia900 on opmbuild |
| 08:03.18 | JaMa | morphis: have you tested new EFL? |
| 08:03.30 | morphis | JaMa: yes |
| 08:03.44 | morphis | JaMa: problem occurs now only at first boot |
| 08:04.21 | morphis | JaMa: with second boot it works fine |
| 08:04.31 | JaMa | but you still have it with that r70387 ? |
| 08:04.37 | morphis | yes |
| 08:04.43 | JaMa | hmm, which device? |
| 08:05.04 | morphis | r70377 |
| 08:05.19 | JaMa | and I guess that if you remove ~/.e then you can reproduce it, right? |
| 08:05.23 | morphis | no sorry, 70387 |
| 08:05.29 | morphis | yes |
| 08:05.40 | morphis | JaMa: I tested it on crespo and om-gta04 |
| 08:05.55 | morphis | JaMa: I will report a bug later on with backtrace etc. |
| 08:06.05 | JaMa | ok, thanks |
| 08:06.08 | morphis | I am currently at university without any device |
| 08:06.13 | *** part/#openmoko-cdevel ildar (~ildar@80.242.212.158) |
| 08:06.22 | JaMa | I've recipes for upcoming release and even newer EFL again :) |
| 08:07.01 | JaMa | but for bump in shr branches I'll wait for release and switch to tarballs |
| 08:08.45 | morphis | yes, that sounds reasonable |
| 08:09.02 | morphis | sticking to releases is always a good idea and will get things more stable in the future |
| 08:09.22 | CIA-45 | SHR: 03Martin.Jansa 07meta-smartphone * r163ed51b910d 10/meta-shr/conf/distro/shr.conf: meta-shr: drop efl-from-svn.inc in preparation for upcoming release |
| 08:11.08 | JaMa | morphis: we can only hope that they will stay compatible with e-wm or python bindings for a while.. |
| 08:11.34 | morphis | yes, let's hope there will be releases of them too |
| 08:11.53 | JaMa | morphis: e.g. if that segfault get fixed in e-wm with some incompatible changes in between |
| 08:12.05 | JaMa | then we would have to backport such patch to meta-efl with same EFL_SRCREV |
| 08:12.27 | JaMa | morphis: or move everything back to _svn recipes |
| 08:13.11 | JaMa | doesn't like local patches to meta-efl, because they usually need rebase or remove with EFL_SRCREV bump so more local changes to try newer EFL |
| 08:13.32 | morphis | JaMa: I would prefer with sticking to real released and backport patches |
| 08:13.49 | JaMa | morphis: btw that PRINC bump in systemd-machine-units morphis/pending wasn't really helpfull right? |
| 08:13.54 | morphis | no |
| 08:14.15 | JaMa | because systemd-machine-units was added to meta-oe together with all BSP appends, so I haven't included PRINC |
| 08:14.16 | morphis | I first thought that would be the problem but then discovered that the package does not contains the *.service files |
| 08:14.21 | morphis | ok |
| 08:14.32 | morphis | I will revert that patch anyway |
| 08:16.16 | JaMa | yes but for that we need all components released |
| 08:16.51 | JaMa | e.g. with e-wm_17.bb and e-wm_svn.bb it will be easy to backport patches only to e-wm_17.bb and keep e-wm_svn.bb tracking HEAD |
| 08:17.23 | morphis | ah yeah, that kind of problem |
| 08:17.36 | morphis | but I think they will keep e-wm compatible with the latest efl release |
| 08:18.59 | JaMa | it wasn't for long with 1.1 release :) but we'll see |
| 08:19.16 | JaMa | and e-wm release is next so it shouldn't take long |
| 08:19.34 | JaMa | and then switch to one big source tree in git :) |
| 08:21.14 | morphis | I think 1.2 or whatever release of EFL is the last one before e-wm will be compatible with it's release |
| 08:21.21 | morphis | as there is tizen which is using e-wm too |
| 08:21.30 | morphis | and all of that E17 stuff is used in it |
| 08:21.40 | morphis | and I think they want stable, released versions too |
| 08:21.54 | CIA-45 | SHR: 03shr-devel 07buildhistory * r0266da60d37c 10/packages/om_gta04-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201204241008 of shr 20120424 for machine om-gta04 on opmbuild |
| 08:24.11 | morphis | JaMa: btw. is there anything you as distro maintainer want to change in the FSO stack? |
| 08:26.19 | JaMa | is's not as distro maintainer, but in general we suck on error reporting |
| 08:26.37 | JaMa | e.g. if you don't have snd module loaded or something else is wrong |
| 08:26.46 | morphis | ok |
| 08:26.55 | JaMa | fsodeviced will fail with glib error about index |
| 08:27.02 | morphis | you mean when something crashes or just something is wrong in system configuration? |
| 08:27.19 | JaMa | and even with debug log it's not really easy to guess that it's because of scenario |
| 08:28.05 | morphis | JaMa: you know apport? |
| 08:28.14 | JaMa | apport? |
| 08:28.35 | morphis | it's the ubuntu service to get known about system application crashes |
| 08:28.59 | morphis | https://wiki.ubuntu.com/Apport |
| 08:29.34 | morphis | thats for the big system |
| 08:29.45 | JaMa | in this case would be great to show e.g. gsmhandset scenario cannot be loaded because "42:'3D Switch':1:0" is not available, or even because sndcard is not available and just disable alsa plugin or something like that instead of crashing whole fsodeviced |
| 08:29.51 | morphis | just in case of that scenario problem we should improve just the error logging in fsodeviced/fsoaudiod |
| 08:30.14 | morphis | JaMa: thats a bug then |
| 08:30.39 | morphis | if it crashes cause something it expects is not available it's a bug and should be fixed |
| 08:31.22 | JaMa | apport is nice, but not sure if it would be popular on small devices like phones (but very usefull) |
| 08:31.44 | morphis | apport does a lot which is maybe too much for devices like a phone |
| 08:32.04 | morphis | but it would help a lot as people often don't know what they need to attach to a bug report |
| 08:32.26 | JaMa | and apport wouldn't be very usefull e.g. for fsodeviced crash if it doesn't store reports to send them later when network gets available :) |
| 08:32.41 | morphis | and apport does all of that automatically so you just have to approve the upload of the bug report |
| 08:33.03 | morphis | yes, thats something essential for a phone |
| 08:34.10 | JaMa | as 1st step I think we should try to make our apps/libs more robust |
| 08:34.46 | JaMa | at least for "common" misconfigurations/issues like scenarios (ML has many reports about them) |
| 08:35.14 | morphis | yes |
| 08:35.39 | morphis | thats something very critical we missed in the past for the whole stack (SHR and FSO) |
| 08:36.09 | JaMa | really has to do some daywork today, bbl |
| 08:36.19 | morphis | JaMa: no problem, go for it |
| 08:37.17 | JaMa | I'll ping you if I find something about systemd-machine-units |
| 08:41.50 | morphis | JaMa: ok |
| 08:42.09 | CIA-45 | SHR: 03shr-devel 07buildhistory * r7fe1dd14b385 10/packages/palmpre-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201204241028 of shr 20120424 for machine palmpre on opmbuild |
| 08:46.36 | *** join/#openmoko-cdevel Mirv (~tajyrink@ubuntu/member/mirv) |
| 08:52.23 | CIA-45 | freesmartphone.org: 03morphis 07cornucopia * re1567c81cbfe 10/fsogsmd/AUTHORS: fsogsmd: add myself to the list of authors |
| 08:52.24 | CIA-45 | freesmartphone.org: 03morphis 07cornucopia * r470a5b351015 10/fsogsmd/src/ (26 files in 26 dirs): fsogsmd: refactor automake configuration |
| 08:57.32 | *** join/#openmoko-cdevel alabd (tvvpwah@unaffiliated/alabd) |
| 09:02.44 | CIA-45 | SHR: 03shr-devel 07buildhistory * r9601dd9a3a3e 10/packages/palmpre2-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201204241048 of shr 20120424 for machine palmpre2 on opmbuild |
| 09:26.03 | CIA-45 | SHR: 03shr-devel 07buildhistory * rfe1b13c063ac 10/images/crespo/eglibc/chroot-image/ (build-id installed-package-sizes.txt): images: Build 201204241109 of shr 20120424 for machine crespo on opmbuild |
| 09:28.48 | *** join/#openmoko-cdevel morphis (~morphis@hfw-ext-wlan.rz.hs-bremen.de) |
| 09:34.51 | CIA-45 | SHR: 03shr-devel 07buildhistory * re00d80e3100b 10/packages/crespo-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201204241133 of shr 20120424 for machine crespo on opmbuild |
| 10:04.16 | *** join/#openmoko-cdevel lamikr (lamikr@nat/nokia/x-fpkvbicdurdufpah) |
| 10:06.47 | *** join/#openmoko-cdevel alabd (urer@unaffiliated/alabd) |
| 10:11.31 | morphis | mrmoku: you know about ALSA UCM? |
| 10:13.51 | mrmoku | yeah, read about it |
| 10:14.13 | morphis | mrmoku: what do you think about it? |
| 10:14.40 | mrmoku | moment... |
| 10:14.42 | mrmoku | on phone |
| 10:14.44 | morphis | ok |
| 10:28.30 | *** join/#openmoko-cdevel plotr1 (~name@dnm.115.84.126.92.dsl.krasnet.ru) |
| 10:34.47 | CIA-45 | SHR: 03shr-devel 07buildhistory * rdb0eafd3179c 10/packages/om_gta02-oe-linux-gnueabi/systemd-machine-units/ (4 files in 4 dirs): packages: Build 201204241233 of shr 20120424 for machine om-gta02 on opmbuild |
| 10:35.34 | *** join/#openmoko-cdevel ThibG (~ThibG@spike.sitedethib.com) |
| 11:01.31 | *** join/#openmoko-cdevel lamikr (lamikr@nat/nokia/x-spwmyedignokfikr) |
| 11:02.11 | mrmoku | hmm... too late |
| 11:05.39 | CIA-45 | SHR: 03shr-devel 07buildhistory * r31204f1df48b 10/packages/om_gta02-oe-linux-gnueabi/systemd-machine-units/ (4 files in 4 dirs): packages: Build 201204241305 of shr 20120424 for machine om-gta02 on opmbuild |
| 11:17.04 | CIA-45 | SHR: 03shr-devel 07buildhistory * r54270913d38e 10/packages/crespo-oe-linux-gnueabi/systemd-machine-units/ (4 files in 4 dirs): packages: Build 201204241316 of shr 20120424 for machine crespo on opmbuild |
| 11:32.38 | *** join/#openmoko-cdevel morphis (~morphis@hfw-ext-wlan.rz.hs-bremen.de) |
| 11:32.45 | mrmoku | yo morphis |
| 11:32.46 | mrmoku | now |
| 11:32.58 | morphis | mrmoku: yeah |
| 11:33.00 | mrmoku | I don't remember well... on first sight it looked like what we need |
| 11:33.05 | mrmoku | but it had flaws |
| 11:33.14 | mrmoku | guess DocScrutinizer might remember the details |
| 11:33.26 | mrmoku | or I could grep my IRC logs |
| 11:36.10 | morphis | flaws in general or for special situations? |
| 11:39.34 | *** join/#openmoko-cdevel Alex[sp3dev] (~alexander@85.202.228.18) |
| 11:39.53 | mrmoku | morphis: sorry, I don't remember... and situation might have changed meanwhile as it is quite long ago |
| 11:40.15 | mrmoku | I think it was about UCM needed modifications to apps |
| 11:41.01 | morphis | mrmoku: as I am thinking about if its worth to got forward without our way to just switch to what linaro people are proposing to be the std. for mobile devices |
| 11:41.49 | mrmoku | good question... |
| 11:42.10 | mrmoku | we're so few devs that we must take what is acceptable |
| 11:42.12 | morphis | I don't understand it very well yet but it sounds nice |
| 11:42.17 | morphis | yes |
| 11:42.40 | *** join/#openmoko-cdevel toams (~tommi@94-224-18-34.access.telenet.be) |
| 11:43.03 | morphis | mrmoku: I also thought about the headache Gnutoo had with the GTA04 and the audio forwarding |
| 11:43.16 | mrmoku | morphis: got a link to what they think should be std. ? |
| 11:43.58 | morphis | mrmoku: do real link but there are many blueprints on launchpad.net about this |
| 11:44.04 | JaMa | morphis: the problem with systemd-machine-units is that, INHERIT_append_crespo = " systemd" doesn't work |
| 11:44.11 | mrmoku | ok |
| 11:44.13 | morphis | JaMa: ah ok |
| 11:44.20 | morphis | mrmoku: let me look |
| 11:44.43 | JaMa | morphis: it shows in -e INHERIT, but some systemd checks are during parsing so I guess this is too late |
| 11:44.59 | JaMa | morphis: will try to change systemd.bbclass to allow empty SYSTEMD_SERVICE |
| 11:45.01 | morphis | mrmoku: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1111/AudioIntegration/UCMPulseAudio |
| 11:45.06 | JaMa | and then inherit it for all |
| 11:45.07 | morphis | mrmoku: https://launchpad.net/linaro-multimedia-ucm |
| 11:45.15 | JaMa | and gpsd almost fixed |
| 11:45.21 | morphis | JaMa: yeah! |
| 11:50.49 | mrmoku | has problems with launchpad |
| 11:50.54 | mrmoku | that's all just plain confusing :-/ |
| 11:51.04 | morphis | mrmoku: https://wiki.linaro.org/Events/2011-06-MMWG/Audio |
| 11:53.31 | *** join/#openmoko-cdevel leviathan (~quassel@2001:470:26:484:6ef0:49ff:fee6:8dca) |
| 11:53.43 | mrmoku | [mok@gonzales ~]$ alsaucm listcards |
| 11:53.44 | mrmoku | ALSA lib parser.c:1261:(uc_mgr_scan_master_configs) error: could not scan directory /usr/share/alsa/ucm: No such file or directory |
| 12:00.39 | mrmoku | morphis: what did you want to say about gnutto/gta04/forwarding ? |
| 12:06.48 | morphis | mrmoku: I thought about using pulseaudio for this task |
| 12:07.26 | morphis | as it should support something like this and is supported but a lot of people and companies |
| 12:09.45 | morphis | mrmoku: I am no talking here about doing anything but just thinking if we should support fsoaudiod in the FSO stack anymore |
| 12:11.38 | *** join/#openmoko-cdevel toams (~tommi@94-224-18-34.access.telenet.be) |
| 12:16.13 | mrmoku | morphis: we did not even start yet to really support it ;) |
| 12:16.20 | morphis | mrmoku: I know :) |
| 12:16.25 | mrmoku | and you're thinking about dropping it? :P |
| 12:16.28 | mrmoku | hmm |
| 12:16.37 | mrmoku | what could be the replacement? |
| 12:16.45 | morphis | don't really know |
| 12:17.01 | morphis | I just want we think about it before doing something we can easily revert later |
| 12:17.14 | mrmoku | yeah |
| 12:17.27 | morphis | easily maybe the wrong word but you know what I mean |
| 12:17.41 | mrmoku | sure |
| 12:18.14 | mrmoku | we really have to accept the fact that we're not enough developers to do what we would consider the 'right' thing |
| 12:18.59 | mrmoku | udev for example... came back via systemd |
| 12:19.29 | mrmoku | and even if we (or at least some of us :P) dislike it and consider it unnecessary... it makes life easier to have it probably |
| 12:20.53 | mrmoku | I just don't know what that exactly means for audio |
| 12:21.25 | mrmoku | PA is something which got dropped loooong time ago because gta02 was too slow for it |
| 12:21.41 | mrmoku | we still want to support gta02 |
| 12:21.42 | mrmoku | I think |
| 12:21.46 | morphis | I hope so |
| 12:22.15 | mrmoku | and using PA only for some architectures... dunno if I'd like that |
| 12:22.21 | morphis | In my case I am just thinking about what I want to maintain |
| 12:22.32 | morphis | as the FSO stack is currently not very small |
| 12:22.36 | mrmoku | :) |
| 12:22.47 | morphis | too much daemons for too much stuff |
| 12:23.01 | mrmoku | that is a completely different thing though... you maintain what *you want* to maintain |
| 12:23.03 | morphis | and stuff which is already done elsewhere |
| 12:23.24 | morphis | yes but there is also the aim to drive the platform as complete thing forward |
| 12:23.30 | morphis | and SHR is currently the only user of it |
| 12:23.39 | morphis | so have to take care of it |
| 12:24.11 | morphis | I do what I want, yes but if people are then using the stuff I do is another story |
| 12:28.28 | mrmoku | morphis: do you still think fsoaudiod would be the correct way to go? not considering man power? |
| 12:29.02 | mrmoku | DocScrutinizer: did you ever take a look at tinyalsa or libsalsa ? |
| 12:29.28 | morphis | mrmoku: I don't really know |
| 12:29.32 | mrmoku | ok |
| 12:29.48 | morphis | mrmoku: we have to take a look at the other things like ALSA UCM and PulseAudio |
| 12:32.39 | morphis | for myself and FSO I gave up the plan to have a device which I can use as a daily phone |
| 12:34.23 | mrmoku | heh, ok |
| 12:34.51 | morphis | I will continue working on FSO and integrate it in SHR/Debian/Ubuntu/Whatever |
| 12:34.55 | morphis | but thats it |
| 12:35.05 | mrmoku | fair enough |
| 12:35.08 | morphis | more isn't doable with my time |
| 12:41.26 | morphis | mrmoku: I am thinking about simplifying the stack in different ways |
| 12:41.30 | JaMa | sad but true :/ |
| 12:41.38 | *** join/#openmoko-cdevel plotr (~name@unaffiliated/plotr) |
| 12:42.00 | morphis | Gnutoo said it already, we're all good in some things |
| 12:42.24 | morphis | I will continue what I can do best |
| 12:44.41 | morphis | there are some steps on my list to clean up the FSO stack |
| 12:44.49 | morphis | for example merging libfsosystem and libfsobasics |
| 12:45.02 | morphis | it makes no sense to have two different libraries |
| 12:45.41 | mrmoku | ok |
| 12:49.38 | morphis | and for example fsodatad |
| 12:50.48 | morphis | there is currently only one use case where it makes sense: providing provision data for fsogsmd |
| 12:51.21 | mrmoku | provision data? |
| 12:51.55 | morphis | provider name etc. |
| 12:52.02 | morphis | for a MCC/MNC |
| 12:52.11 | mrmoku | yeah |
| 12:52.42 | mrmoku | isn't fsotdld using it too? |
| 12:52.45 | morphis | but I need to talk to mickey_office about those stuff |
| 12:52.49 | morphis | maybe |
| 12:53.08 | mrmoku | to know the timezone? |
| 12:54.31 | morphis | yeah |
| 12:54.39 | morphis | you're right |
| 12:58.59 | morphis | mrmoku: you said udev is back in SHR? |
| 12:59.34 | mrmoku | morphis: I think so |
| 12:59.37 | mrmoku | JaMa: ^^ ? |
| 12:59.39 | JaMa | yes |
| 13:00.18 | morphis | causes of systemd? |
| 13:01.41 | JaMa | yes |
| 13:01.55 | JaMa | we can try to get rid of it again later |
| 13:02.03 | morphis | don't know if we should |
| 13:02.11 | mrmoku | a lot later... maybe |
| 13:02.16 | JaMa | but it's not so slow anymore, so no big issue |
| 13:03.37 | mrmoku | ok, given all that I will move systemd integration on top of my list and suspend work on the forwarder until we're clear about where to go |
| 13:04.15 | morphis | mrmoku: systemd integration? |
| 13:05.47 | mrmoku | fixing glitches we got by switching to it |
| 13:05.54 | mrmoku | like things not starting |
| 13:06.05 | mrmoku | getting rid of the last initscripts |
| 13:06.11 | mrmoku | (if JaMa did not beat me once again) |
| 13:07.09 | morphis | ah ok |
| 13:07.10 | morphis | yes |
| 13:07.23 | morphis | should be have a higher priority right now |
| 13:07.29 | morphis | s/be// |
| 13:09.01 | radekp | JaMa: morphis: regarding udev - i think only slowness of are the initial events |
| 13:09.32 | radekp | where it writes to all those uevent files in /sys |
| 13:09.49 | JaMa | mrmoku: I think I did already :) |
| 13:10.00 | JaMa | mrmoku: no initscripts in last 2 staiging feeds |
| 13:10.22 | mrmoku | damn :P |
| 13:12.52 | morphis | mrmoku: so back to profiling the forwarder :) |
| 13:13.05 | mrmoku | ;) |
| 13:13.10 | morphis | radekp: when it populates /dev? |
| 13:13.19 | radekp | morphis: yup |
| 13:13.42 | morphis | whats with udev and devtmpfs, all /dev files should be there automatically with devtmpfs |
| 13:13.43 | radekp | that is my impression - the message about populating takes like 3s ? |
| 13:13.47 | morphis | what then left of udev to do? |
| 13:13.51 | morphis | hm |
| 13:14.19 | morphis | s/of/for/ |
| 13:14.25 | radekp | the difference between udev and devtmps is that devtmpfs works since kernel starts initializing |
| 13:14.36 | morphis | yes |
| 13:14.39 | *** join/#openmoko-cdevel Alex[sp3dev] (~alexander@85.202.228.18) |
| 13:14.45 | radekp | but udev jumps in too late - when userspace is started |
| 13:14.58 | morphis | but when /dev is already populated by devtmpfs why udev needs to do it again |
| 13:15.04 | morphis | it's already done |
| 13:15.14 | radekp | so they touch all those uvent files to know which all hardware the device has |
| 13:15.24 | radekp | because of udev rules |
| 13:15.36 | radekp | you can define e.g. ownership in udev |
| 13:15.40 | morphis | yes, but that should be done in parallel to system bootup |
| 13:15.48 | radekp | devtmpfs assigns all to root |
| 13:15.55 | morphis | as the system already has everything it needs |
| 13:16.20 | morphis | radekp: but you're on debian without systemd, right? |
| 13:16.38 | CIA-45 | SHR: 03Martin.Jansa 07meta-smartphone * r4cd89b7b7ac9 10/ (3 files in 3 dirs): meta-smartphone: drop INHERIT_append_foo now with inherit systemd in .bb and PRINC |
| 13:16.39 | radekp | no - i am using squeeze - it has classical init v |
| 13:17.08 | morphis | ok, then udev delays system boot |
| 13:17.16 | morphis | when using systemd it should not |
| 13:17.20 | radekp | ahh oki |
| 13:17.46 | morphis | (if I am right and understand the systemd blaa correctly) |
| 13:17.58 | radekp | i would be not so sure about it ;-) |
| 13:18.21 | morphis | systemd is growing to fast for me to keep up with it's features |
| 13:18.52 | radekp | e.g. the wifi situation on GTA04 - you need udev to provide firmware for it |
| 13:19.16 | morphis | yes |
| 13:19.21 | morphis | we have fsosystemd for it |
| 13:19.32 | morphis | it does the firmware loading without udev |
| 13:19.39 | radekp | and if networking depends on wifi, you might need to populate the /dev first with udev |
| 13:19.52 | morphis | it's already by devtmpfs |
| 13:20.00 | *** join/#openmoko-cdevel plotr1 (~name@dnm.21.46.188.95.dsl.krasnet.ru) |
| 13:21.00 | radekp | but if you boot just with devtmpfs you will have no wifi at all |
| 13:21.50 | morphis | why? |
| 13:21.55 | morphis | cause of firmware? |
| 13:21.58 | radekp | yes |
| 13:22.08 | morphis | <morphis> we have fsosystemd for it |
| 13:22.59 | morphis | whenever a module requests firmware via default firmware interface in kernel fsosystemd is able to load it |
| 13:23.11 | radekp | but if it is not module? |
| 13:23.22 | radekp | if the wifi driver is compiled in kernel |
| 13:23.32 | morphis | yes thats another thing ... |
| 13:23.38 | radekp | you will never notice that the device has wifi card |
| 13:23.44 | morphis | thats done with enabling the WiFi resource in FSO |
| 13:23.52 | radekp | unless you start touching all the uevent files |
| 13:24.00 | *** join/#openmoko-cdevel Alex[sp3dev] (~alexander@178.176.126.21) |
| 13:24.22 | morphis | you know that the device has a WiFi card |
| 13:24.49 | morphis | with FSO you requests the WiFi resource whenever you want to use WiFi |
| 13:25.17 | radekp | but this is quite agains the linux philosophy - that the hardware should just work without any configuration files |
| 13:25.22 | morphis | then there is a plugin in fsodeviced which does the steps needed to enable wifi (loading modules, sysfs-configuration, ...) |
| 13:25.56 | morphis | it's for embedded systems to keep stuff minimal |
| 13:25.58 | radekp | and udev is quite nicely doing this automatically - but the downside is the booting delay |
| 13:26.01 | morphis | and just target one specific device |
| 13:26.07 | morphis | yes |
| 13:26.18 | morphis | that was one of the decision why this was done |
| 13:26.26 | morphis | not saying I am happy with this |
| 13:26.29 | radekp | oki - if this is just for one device and for given hw set it works |
| 13:27.15 | morphis | in a lot devices you can't disable WiFi without unloading the kernel module |
| 13:27.25 | morphis | no rfkill etc. |
| 13:27.41 | radekp | oki |
| 13:28.02 | radekp | btw i think udev could be quite fast if we had as many things as possible as modules |
| 13:28.24 | radekp | because udev would not touch so many files and the /dev populating would be fast |
| 13:28.47 | radekp | and then when you load module udev can just read it on netlink... |
| 13:29.15 | morphis | fsodeviced supports also rfkill for Wifi, ... but then the kernel needs to support this too which is not the case for all the Nexus S, Palm Pre, HTC XY, ... |
| 13:29.30 | radekp | and booting would be also faster - i think current kernel is quite big |
| 13:29.42 | morphis | radekp: maybe |
| 13:29.49 | radekp | you cant even flash it in nand |
| 13:31.29 | radekp | has to go... cu |
| 13:34.18 | morphis | radekp: cya |
| 13:35.14 | *** join/#openmoko-cdevel matr0 (~matr0@e178135187.adsl.alicedsl.de) |
| 13:42.29 | *** join/#openmoko-cdevel jackh (~quassel@114.86.191.41) |
| 13:48.02 | morphis | JaMa: I get the following with latest shr and systemd: http://paste.pocoo.org/show/586502/ |
| 13:58.27 | morphis | JaMa: and a possible but dirty fix: http://paste.pocoo.org/show/586514/ |
| 13:59.33 | *** join/#openmoko-cdevel alabd (rqjdc@unaffiliated/alabd) |
| 14:08.02 | morphis | JaMa: but packaging systemd-machine-units for crespo now works as expected |
| 14:15.02 | JaMa | morphis: maybe we can set empty string in systemd-machine-units_1.0.bb |
| 14:15.10 | JaMa | instead of or "" on many places |
| 14:15.12 | morphis | yes |
| 14:15.27 | morphis | a better solution than what I did :) |
| 14:15.32 | JaMa | but weird I've tried to build it with palmpre (also should be empty) and it haven't failed |
| 14:15.47 | morphis | hm |
| 14:17.10 | morphis | let's see if it works on the device |
| 14:31.25 | *** join/#openmoko-cdevel plotr (~name@unaffiliated/plotr) |
| 14:33.12 | *** join/#openmoko-cdevel soltys (soltys@czaj.net) |
| 15:13.32 | CIA-45 | SHR: 03shr-devel 07buildhistory * r8959ba835da6 10/images/crespo/eglibc/chroot-image/ (build-id installed-package-sizes.txt): images: Build 201204241701 of shr 20120424 for machine crespo on opmbuild |
| 15:19.47 | *** join/#openmoko-cdevel GNUtoo-desktop (~GNUtoo@host137-129-dynamic.45-79-r.retail.telecomitalia.it) |
| 15:55.46 | DocScrutinizer51 | mrmoku: nope |
| 15:58.28 | DocScrutinizer51 | mrmoku: whats tinyalsa? |
| 16:11.10 | *** join/#openmoko-cdevel zrafa (~rafa@190.14.174.29) |
| 16:25.19 | *** join/#openmoko-cdevel dos11 (~dos@unaffiliated/dos1) |
| 16:31.09 | *** join/#openmoko-cdevel GarthPS (~quassel@2a01:e35:2f5c:e670:b892:4df1:6e5f:f5d) |
| 16:44.12 | *** join/#openmoko-cdevel ege_ (~erik@2001:1620:f64:0:c0cd:fc3a:beb0:ce73) |
| 16:58.03 | mrmoku | DocScrutinizer51: some alternative libasound as well |
| 16:58.31 | mrmoku | https://github.com/tinyalsa/tiny |
| 16:58.38 | mrmoku | err |
| 16:58.43 | mrmoku | -tiny |
| 17:00.35 | CIA-45 | SHR: 03shr-devel 07buildhistory * r87a6ec572bc3 10/packages/om_gta02-oe-linux-gnueabi/systemd-machine-units/ (7 files in 7 dirs): packages: Build 201204241856 of shr 20120424 for machine om-gta02 on opmbuild |
| 17:01.39 | CIA-45 | SHR: 03shr-devel 07buildhistory * r2615da8f9380 10/packages/nokia900-oe-linux-gnueabi/systemd-machine-units/ (7 files in 7 dirs): packages: Build 201204241900 of shr 20120424 for machine nokia900 on opmbuild |
| 17:03.36 | *** join/#openmoko-cdevel pespin (~pespin@176.pool85-50-88.dynamic.orange.es) |
| 17:05.13 | CIA-45 | SHR: 03shr-devel 07buildhistory * rfaa090a7fd98 10/packages/crespo-oe-linux-gnueabi/systemd-machine-units/ (7 files in 7 dirs): packages: Build 201204241904 of shr 20120424 for machine crespo on opmbuild |
| 17:13.24 | *** join/#openmoko-cdevel morphis (~morphis@dslb-092-076-166-196.pools.arcor-ip.net) |
| 17:20.06 | JaMa | fsck 14 commits to teach scons to build gpsd correctly :/ |
| 17:20.42 | JaMa | feel free to test jansa/gpsd branch |
| 17:21.39 | JaMa | off |
| 17:38.51 | *** join/#openmoko-cdevel pbaxter (~pbaxter@host58-149-dynamic.40-79-r.retail.telecomitalia.it) |
| 17:43.21 | *** part/#openmoko-cdevel zrafa (~rafa@190.14.174.29) |
| 17:45.04 | *** join/#openmoko-cdevel Heinervdm (~thomas@p5B0F56C0.dip.t-dialin.net) |
| 17:51.22 | *** join/#openmoko-cdevel dos11 (~dos@unaffiliated/dos1) |
| 17:51.48 | *** join/#openmoko-cdevel NIN101 (~NIN@2606:df00:2:0:216:3cff:fe71:5e1e) |
| 17:54.03 | rines | does anybody use current shr-core on palm pre (plus)? |
| 17:55.10 | rines | I got a new pre plus today and after http://shr-project.org/trac/wiki/Devices/PalmPre/InstallGuide it always stays at "palm" bootup logo |
| 17:55.49 | rines | I'm not sure if it's system or shr related; some people had bootup problems with webOS, too |
| 17:55.50 | JaMa | you can try shr-2012.1, but palm pre does not work with systemd |
| 17:56.01 | rines | ah |
| 17:57.39 | rines | JaMa: I installed bootr so I should see a bootloader before it "crashes"!? |
| 17:57.55 | DocScrutinizer51 | mrmoku: looking into it |
| 17:58.16 | JaMa | rines: I don't have any palm.. so dunno |
| 17:58.31 | rines | hmm.. okay; will try it again ;) |
| 17:58.42 | JaMa | but in theory bootloader should be still able to start init |
| 17:58.52 | JaMa | err kernel and kernel start init |
| 17:59.09 | rines | yes, but I cannot see any bootloader as well; so I think (and hope) it was palm system related |
| 18:01.51 | DocScrutinizer51 | ...later, as it's a PITA on N900 |
| 18:05.00 | mrmoku | DocScrutinizer51: yeah better on something bigger :) |
| 18:10.48 | *** join/#openmoko-cdevel SabotageAndi (~SabotageA@h081217018227.dyn.cm.kabsi.at) |
| 18:14.59 | DocScrutinizer | indeed |
| 18:18.22 | DocScrutinizer | just chill out from 10 hours debugging a buffer oberrun on a 5-fold bidir FIFO with buffers per FIFO in the phy layer driver, wrapped into a logical layer implementig arbitrary number of logical channels per FIFO, each with buffer *plus* 4 double-linked lists for new, waiting, done msg and empty msg buffers |
| 18:19.15 | DocScrutinizer | so basically 4 layers of buffers: hw, sw-phy, sw-log, and msg-lists |
| 18:20.12 | DocScrutinizer | of course IRQ driven |
| 18:20.43 | DocScrutinizer | MEH! |
| 18:21.02 | *** join/#openmoko-cdevel Orias_Korva (~atilla@94-227-86-16.access.telenet.be) |
| 18:27.26 | *** join/#openmoko-cdevel radek_ (~radek@63.120.broadband10.iol.cz) |
| 18:44.10 | Azog | DocScrutinizer: you have to go deeper |
| 18:46.22 | *** join/#openmoko-cdevel anarsoul (~anarsoul@212.98.184.90) |
| 18:47.27 | *** join/#openmoko-cdevel plotr (~name@unaffiliated/plotr) |
| 19:01.19 | *** join/#openmoko-cdevel plotr (~name@unaffiliated/plotr) |
| 19:22.06 | *** join/#openmoko-cdevel morphis (~morphis@dslb-092-076-166-196.pools.arcor-ip.net) |
| 19:26.44 | *** join/#openmoko-cdevel slyon (~lukas@ppp-93-104-83-242.dynamic.mnet-online.de) |
| 19:27.03 | slyon | yo! |
| 19:27.45 | morphis | slyon: heyho |
| 19:28.05 | CIA-45 | freesmartphone.org: 03morphis 07cornucopia * rd236b3144cbe 10/fsogsmd/ (2 files in 2 dirs): fsogsmd: lowlevel_gta04: extend modem power on/off logic to be more reliable |
| 19:28.05 | CIA-45 | freesmartphone.org: 03morphis 07cornucopia * rd70a5c1a2d89 10/fsogsmd/src/ (4 files in 3 dirs): fsogsmd: lib: refactor usage of sms storage to be based on an interface |
| 19:28.06 | slyon | i've just read in the backlog, that udev is back again. |
| 19:28.07 | CIA-45 | freesmartphone.org: 03morphis 07cornucopia * r3b7603547a24 10/fsogsmd/src/lib/at/atsms.vala: fsogsmd: lib: at: make our at-based sms handler inherit from the generic handler |
| 19:28.07 | CIA-45 | freesmartphone.org: 03morphis 07cornucopia * r42dc81b1181b 10/fsogsmd/tests/testsms.vala: fsogsmd: tests: adjust SMS tests for recent changes to SMS storage class |
| 19:28.08 | CIA-45 | freesmartphone.org: 03morphis 07cornucopia * r050dd6fa38be 10/old/ (66 files in 16 dirs): Remove old code finally |
| 19:28.17 | morphis | slyon: I extended your lowlevel_gta04 plugin a little bit |
| 19:28.22 | slyon | cool |
| 19:29.04 | slyon | morphis, do you know where to integrade udev rules in OE? as udev is back again in shr, we should use the rules form the gta04-owner ML to have stable HSO interfaces |
| 19:30.00 | morphis | slyon: yes we should, but I don't know where too |
| 19:30.03 | morphis | JaMa should know |
| 19:30.18 | morphis | slyon: please write him a mail or I will tell him tomorrow |
| 19:30.51 | slyon | morphis, yes. I'll ask jama |
| 19:31.48 | slyon | morphis, in the lowlevel_gta04 config you're using the /dev/ttyHS_Application interface already |
| 19:31.56 | slyon | is this intended? |
| 19:33.20 | morphis | I didn't tested it |
| 19:33.27 | morphis | but thats what I have from the mailinglist |
| 19:33.42 | slyon | ttyHS_Application is created by udev |
| 19:33.44 | morphis | yes |
| 19:33.51 | morphis | I had the same thought as you |
| 19:34.06 | slyon | if you don't have the rules it's (mostly) ttyHS3 |
| 19:34.27 | morphis | I first had there ttyHS3 |
| 19:34.30 | slyon | ok. so we just integrate the udev rules. there is one more for the vibra call motor |
| 19:34.38 | morphis | ok |
| 19:34.48 | morphis | do we need to adjust them for integration? |
| 19:34.49 | slyon | I'll take care about the udev rules |
| 19:34.53 | morphis | great |
| 19:35.49 | slyon | i don't think we need to adjust them. but I'll adjust the fsogsmd.conf once the udev rules are in |
| 19:36.23 | morphis | slyon: but please take care that you're using fso-autorev.inc |
| 19:36.42 | morphis | as shr-core uses release tarballs of the FSO components now |
| 19:37.05 | slyon | morphis, one completly different question i stumbled upon several times: what is public override string repr() used for? It's in every FSO class... |
| 19:37.16 | slyon | ok will use fso-autorev.inc |
| 19:37.27 | morphis | yes, that is inherited from the AbstractObject class |
| 19:37.30 | *** join/#openmoko-cdevel plotr (~name@unaffiliated/plotr) |
| 19:37.37 | morphis | it's part of the logging mechanism we have |
| 19:38.05 | slyon | what can I /should I specify there? most of the time it's just "<>" |
| 19:38.09 | morphis | as base pattern we're using <classname> <log message> as output |
| 19:38.34 | morphis | when using the AbstractObject you have two additional members: config and logger |
| 19:39.06 | morphis | with repr() you have the possiblity to add additional information to the logline |
| 19:39.11 | morphis | think about a class SimMessage |
| 19:39.39 | morphis | per default it logs this with a call to logger.debug(...): "SimMessage: Test Message" |
| 19:40.14 | morphis | with repr() you can extend it to: "SimMessage<1234>: Test Message" where 1234 is the message id |
| 19:41.42 | *** join/#openmoko-cdevel dos11 (~dos@unaffiliated/dos1) |
| 19:42.47 | slyon | ok. I see. so it isn't reserverd for anything special, but gives to opportunity to specify a "group" of logs |
| 19:43.01 | slyon | thanks |
| 19:43.17 | morphis | some sort of this, yes |
| 19:43.23 | morphis | look at http://git.freesmartphone.org/?p=cornucopia.git;a=blob;f=libfsobasics/fsobasics/object.vala;h=7680f435db893288add1e7635de70d97e5fa4362;hb=HEAD#l34 |
| 19:43.45 | morphis | and this http://git.freesmartphone.org/?p=cornucopia.git;a=blob;f=libfsobasics/fsobasics/logger.vala;h=38c4ebda94b97a7c236a89dbb0fb35842c900fb4;hb=HEAD#l202 |
| 19:45.47 | slyon | morphis, about the lowlevel_gta04 plugin: there are suspend() and resume() methods. can those be used to send AT commands? currently we're sending AT_OSQI=0 as a fsogsmd hook on suspend |
| 19:45.56 | slyon | and AT_OSQI=1 on resume |
| 19:46.06 | slyon | should this be part of the lowlevel plugin? |
| 19:46.15 | morphis | no thats no something we should do in the lowlevel plugin |
| 19:46.22 | slyon | ok |
| 19:46.28 | morphis | there are separate suspend/resume methods for the modem class |
| 19:49.46 | *** join/#openmoko-cdevel dos11 (~dos@unaffiliated/dos1) |
| 19:57.11 | *** join/#openmoko-cdevel dos11 (~dos@unaffiliated/dos1) |
| 19:58.25 | *** join/#openmoko-cdevel pwgen (~ew@2.108.92.38) |
| 20:20.48 | slyon | morphis, I've send a patch for the udev rules to shr-devel. JaMa should find it there :) |
| 20:22.30 | slyon | (and review it). will ping him tomorrow about this. |
| 20:22.35 | slyon | I'll leave now. bye! |
| 20:36.15 | *** join/#openmoko-cdevel Martix (~martix@4.177.broadband3.iol.cz) |
| 20:46.28 | *** join/#openmoko-cdevel dos11 (~dos@unaffiliated/dos1) |
| 21:20.55 | *** join/#openmoko-cdevel JaMa (~martin@94.230.152.246) |
| 21:34.29 | JaMa | ls |
| 23:18.41 | *** join/#openmoko-cdevel meskal (~quassel@2a01:238:43ac:1b00:d3d5:b870:6223:169a) |
| 23:52.10 | *** join/#openmoko-cdevel tg (~tg@irc.tgbit.net) |