**** BEGIN LOGGING AT Tue Apr 24 02:59:58 2012 Apr 24 06:17:31 * mrmoku chooses the caffeine overdose protection technique :-) Apr 24 06:20:07 moin Apr 24 06:35:04 moin JaMa Apr 24 06:40:51 SHR: 03shr-devel 07buildhistory * r2f443849e5f6 10/packages/ (65 files in 65 dirs): packages: Build 201204240831 of shr 20120424 for machine om-gta02 on opmbuild Apr 24 06:48:19 Good morning, everyone :) Apr 24 06:51:57 24 hours to EFL release :) time to prepare recipes Apr 24 06:58:25 SHR: 03Martin.Jansa 07shr-chroot * r47a617b67e4d 10/ (1143 files in 28 dirs): system upgrade Apr 24 07:14:32 morning Apr 24 07:14:52 caffeine OD prot tech? drop the cup? Apr 24 07:15:40 DocScrutinizer: the lwn article pabs3 posted... one comment suggests caffeine overdose as protection Apr 24 07:18:39 awesome Apr 24 07:22:44 JaMa: hi, how long is SHR using systemd? Is it possible that the image i have (from 2012/03/15) is without systemd? Apr 24 07:26:12 radekp: yeah, that should have been without systemd Apr 24 07:26:13 SHR: 03shr-devel 07buildhistory * rb9a594ca0af8 10/packages/ (73 files in 73 dirs): packages: Build 201204240857 of shr 20120424 for machine om-gta02 on opmbuild Apr 24 07:26:23 the switch was not long ago Apr 24 07:26:47 ahh oki, maybe systemd is more strict about rootfs remounting Apr 24 07:28:20 btw is boot with systemd faster now? Apr 24 07:28:41 radekp: 041 had the systemd merge... which was merged to public feed on 3rd April Apr 24 07:29:38 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 Apr 24 07:31:25 mrmoku: oki, thanks, i am now trying it :) Apr 24 07:31:41 yw and have fun :-) Apr 24 07:41:45 JaMa: ping Apr 24 07:48:37 *sigh* Apr 24 07:48:44 but it's *new* Apr 24 07:48:49 ;-P Apr 24 07:52:55 morphis: pong Apr 24 07:54:14 JaMa: we have a problem with the systemd-machine-units for the Nexus S Apr 24 07:54:25 JaMa: the service files are not packaged Apr 24 07:54:48 and I don't know how to integrate them the right way Apr 24 07:56:58 looks like multiple entries in SYSTEMD_SERVICE don't realy work Apr 24 07:57:24 no, one entry doesn't work too Apr 24 07:58:26 I also tried with just using SYSTEMD_SERVICE = "..." instead of SYSTEMD_SERVICE_crespo = "..." Apr 24 07:59:59 will try on buildhost after it finishes build Apr 24 08:00:35 ok Apr 24 08:01:01 SHR: 03shr-devel 07buildhistory * r69a20dc61ddc 10/packages/ (73 files in 73 dirs): packages: Build 201204240933 of shr 20120424 for machine nokia900 on opmbuild Apr 24 08:03:18 morphis: have you tested new EFL? Apr 24 08:03:30 JaMa: yes Apr 24 08:03:44 JaMa: problem occurs now only at first boot Apr 24 08:04:21 JaMa: with second boot it works fine Apr 24 08:04:31 but you still have it with that r70387 ? Apr 24 08:04:37 yes Apr 24 08:04:43 hmm, which device? Apr 24 08:05:04 r70377 Apr 24 08:05:19 and I guess that if you remove ~/.e then you can reproduce it, right? Apr 24 08:05:23 no sorry, 70387 Apr 24 08:05:29 yes Apr 24 08:05:40 JaMa: I tested it on crespo and om-gta04 Apr 24 08:05:55 JaMa: I will report a bug later on with backtrace etc. Apr 24 08:06:04 ok, thanks Apr 24 08:06:08 I am currently at university without any device Apr 24 08:06:22 I've recipes for upcoming release and even newer EFL again :) Apr 24 08:07:01 but for bump in shr branches I'll wait for release and switch to tarballs Apr 24 08:08:45 yes, that sounds reasonable Apr 24 08:09:02 sticking to releases is always a good idea and will get things more stable in the future Apr 24 08:09:22 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 Apr 24 08:11:07 morphis: we can only hope that they will stay compatible with e-wm or python bindings for a while.. Apr 24 08:11:34 yes, let's hope there will be releases of them too Apr 24 08:11:52 morphis: e.g. if that segfault get fixed in e-wm with some incompatible changes in between Apr 24 08:12:05 then we would have to backport such patch to meta-efl with same EFL_SRCREV Apr 24 08:12:27 morphis: or move everything back to _svn recipes Apr 24 08:13:10 * 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 Apr 24 08:13:32 JaMa: I would prefer with sticking to real released and backport patches Apr 24 08:13:48 morphis: btw that PRINC bump in systemd-machine-units morphis/pending wasn't really helpfull right? Apr 24 08:13:54 no Apr 24 08:14:15 because systemd-machine-units was added to meta-oe together with all BSP appends, so I haven't included PRINC Apr 24 08:14:16 I first thought that would be the problem but then discovered that the package does not contains the *.service files Apr 24 08:14:21 ok Apr 24 08:14:31 I will revert that patch anyway Apr 24 08:16:16 yes but for that we need all components released Apr 24 08:16:51 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 Apr 24 08:17:23 ah yeah, that kind of problem Apr 24 08:17:36 but I think they will keep e-wm compatible with the latest efl release Apr 24 08:18:59 it wasn't for long with 1.1 release :) but we'll see Apr 24 08:19:15 and e-wm release is next so it shouldn't take long Apr 24 08:19:34 and then switch to one big source tree in git :) Apr 24 08:21:14 I think 1.2 or whatever release of EFL is the last one before e-wm will be compatible with it's release Apr 24 08:21:21 as there is tizen which is using e-wm too Apr 24 08:21:30 and all of that E17 stuff is used in it Apr 24 08:21:40 and I think they want stable, released versions too Apr 24 08:21:54 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 Apr 24 08:24:11 JaMa: btw. is there anything you as distro maintainer want to change in the FSO stack? Apr 24 08:26:19 is's not as distro maintainer, but in general we suck on error reporting Apr 24 08:26:36 e.g. if you don't have snd module loaded or something else is wrong Apr 24 08:26:46 ok Apr 24 08:26:55 fsodeviced will fail with glib error about index Apr 24 08:27:02 you mean when something crashes or just something is wrong in system configuration? Apr 24 08:27:19 and even with debug log it's not really easy to guess that it's because of scenario Apr 24 08:28:04 JaMa: you know apport? Apr 24 08:28:14 apport? Apr 24 08:28:35 it's the ubuntu service to get known about system application crashes Apr 24 08:28:59 https://wiki.ubuntu.com/Apport Apr 24 08:29:34 thats for the big system Apr 24 08:29:45 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 Apr 24 08:29:51 just in case of that scenario problem we should improve just the error logging in fsodeviced/fsoaudiod Apr 24 08:30:14 JaMa: thats a bug then Apr 24 08:30:39 if it crashes cause something it expects is not available it's a bug and should be fixed Apr 24 08:31:22 apport is nice, but not sure if it would be popular on small devices like phones (but very usefull) Apr 24 08:31:44 apport does a lot which is maybe too much for devices like a phone Apr 24 08:32:04 but it would help a lot as people often don't know what they need to attach to a bug report Apr 24 08:32:26 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 :) Apr 24 08:32:41 and apport does all of that automatically so you just have to approve the upload of the bug report Apr 24 08:33:03 yes, thats something essential for a phone Apr 24 08:34:10 as 1st step I think we should try to make our apps/libs more robust Apr 24 08:34:46 at least for "common" misconfigurations/issues like scenarios (ML has many reports about them) Apr 24 08:35:14 yes Apr 24 08:35:38 thats something very critical we missed in the past for the whole stack (SHR and FSO) Apr 24 08:36:09 * JaMa really has to do some daywork today, bbl Apr 24 08:36:19 JaMa: no problem, go for it Apr 24 08:37:17 I'll ping you if I find something about systemd-machine-units Apr 24 08:41:49 JaMa: ok Apr 24 08:42:09 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 Apr 24 08:52:23 freesmartphone.org: 03morphis 07cornucopia * re1567c81cbfe 10/fsogsmd/AUTHORS: fsogsmd: add myself to the list of authors Apr 24 08:52:24 freesmartphone.org: 03morphis 07cornucopia * r470a5b351015 10/fsogsmd/src/ (26 files in 26 dirs): fsogsmd: refactor automake configuration Apr 24 09:02:44 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 Apr 24 09:26:03 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 Apr 24 09:34:51 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 Apr 24 10:11:31 mrmoku: you know about ALSA UCM? Apr 24 10:13:51 yeah, read about it Apr 24 10:14:13 mrmoku: what do you think about it? Apr 24 10:14:40 moment... Apr 24 10:14:42 * mrmoku on phone Apr 24 10:14:43 ok Apr 24 10:34:47 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 Apr 24 11:02:11 hmm... too late Apr 24 11:05:39 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 Apr 24 11:17:04 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 Apr 24 11:32:45 yo morphis Apr 24 11:32:46 now Apr 24 11:32:58 mrmoku: yeah Apr 24 11:33:00 I don't remember well... on first sight it looked like what we need Apr 24 11:33:05 but it had flaws Apr 24 11:33:14 guess DocScrutinizer might remember the details Apr 24 11:33:26 or I could grep my IRC logs Apr 24 11:36:09 flaws in general or for special situations? Apr 24 11:39:53 morphis: sorry, I don't remember... and situation might have changed meanwhile as it is quite long ago Apr 24 11:40:15 I think it was about UCM needed modifications to apps Apr 24 11:41:01 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 Apr 24 11:41:49 good question... Apr 24 11:42:09 we're so few devs that we must take what is acceptable Apr 24 11:42:12 I don't understand it very well yet but it sounds nice Apr 24 11:42:17 yes Apr 24 11:43:03 mrmoku: I also thought about the headache Gnutoo had with the GTA04 and the audio forwarding Apr 24 11:43:16 morphis: got a link to what they think should be std. ? Apr 24 11:43:58 mrmoku: do real link but there are many blueprints on launchpad.net about this Apr 24 11:44:04 morphis: the problem with systemd-machine-units is that, INHERIT_append_crespo = " systemd" doesn't work Apr 24 11:44:11 ok Apr 24 11:44:13 JaMa: ah ok Apr 24 11:44:20 mrmoku: let me look Apr 24 11:44:43 morphis: it shows in -e INHERIT, but some systemd checks are during parsing so I guess this is too late Apr 24 11:44:59 morphis: will try to change systemd.bbclass to allow empty SYSTEMD_SERVICE Apr 24 11:45:01 mrmoku: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1111/AudioIntegration/UCMPulseAudio Apr 24 11:45:06 and then inherit it for all Apr 24 11:45:07 mrmoku: https://launchpad.net/linaro-multimedia-ucm Apr 24 11:45:15 and gpsd almost fixed Apr 24 11:45:21 JaMa: yeah! Apr 24 11:50:49 * mrmoku has problems with launchpad Apr 24 11:50:54 that's all just plain confusing :-/ Apr 24 11:51:04 mrmoku: https://wiki.linaro.org/Events/2011-06-MMWG/Audio Apr 24 11:53:43 [mok@gonzales ~]$ alsaucm listcards Apr 24 11:53:43 ALSA lib parser.c:1261:(uc_mgr_scan_master_configs) error: could not scan directory /usr/share/alsa/ucm: No such file or directory Apr 24 12:00:39 morphis: what did you want to say about gnutto/gta04/forwarding ? Apr 24 12:06:48 mrmoku: I thought about using pulseaudio for this task Apr 24 12:07:26 as it should support something like this and is supported but a lot of people and companies Apr 24 12:09:45 mrmoku: I am no talking here about doing anything but just thinking if we should support fsoaudiod in the FSO stack anymore Apr 24 12:16:13 morphis: we did not even start yet to really support it ;) Apr 24 12:16:20 mrmoku: I know :) Apr 24 12:16:25 and you're thinking about dropping it? :P Apr 24 12:16:28 hmm Apr 24 12:16:37 what could be the replacement? Apr 24 12:16:45 don't really know Apr 24 12:17:01 I just want we think about it before doing something we can easily revert later Apr 24 12:17:14 yeah Apr 24 12:17:27 easily maybe the wrong word but you know what I mean Apr 24 12:17:41 sure Apr 24 12:18:14 we really have to accept the fact that we're not enough developers to do what we would consider the 'right' thing Apr 24 12:18:59 udev for example... came back via systemd Apr 24 12:19:29 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 Apr 24 12:20:53 I just don't know what that exactly means for audio Apr 24 12:21:24 PA is something which got dropped loooong time ago because gta02 was too slow for it Apr 24 12:21:41 we still want to support gta02 Apr 24 12:21:42 I think Apr 24 12:21:46 I hope so Apr 24 12:22:15 and using PA only for some architectures... dunno if I'd like that Apr 24 12:22:21 In my case I am just thinking about what I want to maintain Apr 24 12:22:32 as the FSO stack is currently not very small Apr 24 12:22:36 :) Apr 24 12:22:47 too much daemons for too much stuff Apr 24 12:23:01 that is a completely different thing though... you maintain what *you want* to maintain Apr 24 12:23:03 and stuff which is already done elsewhere Apr 24 12:23:24 yes but there is also the aim to drive the platform as complete thing forward Apr 24 12:23:30 and SHR is currently the only user of it Apr 24 12:23:39 so have to take care of it Apr 24 12:24:11 I do what I want, yes but if people are then using the stuff I do is another story Apr 24 12:28:28 morphis: do you still think fsoaudiod would be the correct way to go? not considering man power? Apr 24 12:29:02 DocScrutinizer: did you ever take a look at tinyalsa or libsalsa ? Apr 24 12:29:28 mrmoku: I don't really know Apr 24 12:29:32 ok Apr 24 12:29:48 mrmoku: we have to take a look at the other things like ALSA UCM and PulseAudio Apr 24 12:32:39 for myself and FSO I gave up the plan to have a device which I can use as a daily phone Apr 24 12:34:23 heh, ok Apr 24 12:34:51 I will continue working on FSO and integrate it in SHR/Debian/Ubuntu/Whatever Apr 24 12:34:55 but thats it Apr 24 12:35:05 fair enough Apr 24 12:35:08 more isn't doable with my time Apr 24 12:41:26 mrmoku: I am thinking about simplifying the stack in different ways Apr 24 12:41:30 sad but true :/ Apr 24 12:42:00 Gnutoo said it already, we're all good in some things Apr 24 12:42:24 I will continue what I can do best Apr 24 12:44:41 there are some steps on my list to clean up the FSO stack Apr 24 12:44:49 for example merging libfsosystem and libfsobasics Apr 24 12:45:02 it makes no sense to have two different libraries Apr 24 12:45:41 ok Apr 24 12:49:38 and for example fsodatad Apr 24 12:50:48 there is currently only one use case where it makes sense: providing provision data for fsogsmd Apr 24 12:51:20 provision data? Apr 24 12:51:55 provider name etc. Apr 24 12:52:02 for a MCC/MNC Apr 24 12:52:11 yeah Apr 24 12:52:42 isn't fsotdld using it too? Apr 24 12:52:45 but I need to talk to mickey_office about those stuff Apr 24 12:52:49 maybe Apr 24 12:53:08 to know the timezone? Apr 24 12:54:31 yeah Apr 24 12:54:39 you're right Apr 24 12:58:59 mrmoku: you said udev is back in SHR? Apr 24 12:59:34 morphis: I think so Apr 24 12:59:37 JaMa: ^^ ? Apr 24 12:59:39 yes Apr 24 13:00:18 causes of systemd? Apr 24 13:01:41 yes Apr 24 13:01:55 we can try to get rid of it again later Apr 24 13:02:03 don't know if we should Apr 24 13:02:11 a lot later... maybe Apr 24 13:02:16 but it's not so slow anymore, so no big issue Apr 24 13:03:37 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 Apr 24 13:04:15 mrmoku: systemd integration? Apr 24 13:05:47 fixing glitches we got by switching to it Apr 24 13:05:54 like things not starting Apr 24 13:06:05 getting rid of the last initscripts Apr 24 13:06:11 (if JaMa did not beat me once again) Apr 24 13:07:09 ah ok Apr 24 13:07:10 yes Apr 24 13:07:23 should be have a higher priority right now Apr 24 13:07:29 s/be// Apr 24 13:07:29 morphis meant: should have a higher priority right now Apr 24 13:09:01 JaMa: morphis: regarding udev - i think only slowness of are the initial events Apr 24 13:09:32 where it writes to all those uevent files in /sys Apr 24 13:09:49 mrmoku: I think I did already :) Apr 24 13:10:00 mrmoku: no initscripts in last 2 staiging feeds Apr 24 13:10:22 damn :P Apr 24 13:12:52 mrmoku: so back to profiling the forwarder :) Apr 24 13:13:05 ;) Apr 24 13:13:10 radekp: when it populates /dev? Apr 24 13:13:19 morphis: yup Apr 24 13:13:42 whats with udev and devtmpfs, all /dev files should be there automatically with devtmpfs Apr 24 13:13:43 that is my impression - the message about populating takes like 3s ? Apr 24 13:13:47 what then left of udev to do? Apr 24 13:13:51 hm Apr 24 13:14:19 s/of/for/ Apr 24 13:14:25 the difference between udev and devtmps is that devtmpfs works since kernel starts initializing Apr 24 13:14:36 yes Apr 24 13:14:45 but udev jumps in too late - when userspace is started Apr 24 13:14:58 but when /dev is already populated by devtmpfs why udev needs to do it again Apr 24 13:15:04 it's already done Apr 24 13:15:13 so they touch all those uvent files to know which all hardware the device has Apr 24 13:15:24 because of udev rules Apr 24 13:15:36 you can define e.g. ownership in udev Apr 24 13:15:40 yes, but that should be done in parallel to system bootup Apr 24 13:15:48 devtmpfs assigns all to root Apr 24 13:15:55 as the system already has everything it needs Apr 24 13:16:20 radekp: but you're on debian without systemd, right? Apr 24 13:16:38 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 Apr 24 13:16:39 no - i am using squeeze - it has classical init v Apr 24 13:17:08 ok, then udev delays system boot Apr 24 13:17:16 when using systemd it should not Apr 24 13:17:20 ahh oki Apr 24 13:17:46 (if I am right and understand the systemd blaa correctly) Apr 24 13:17:58 i would be not so sure about it ;-) Apr 24 13:18:21 systemd is growing to fast for me to keep up with it's features Apr 24 13:18:52 e.g. the wifi situation on GTA04 - you need udev to provide firmware for it Apr 24 13:19:16 yes Apr 24 13:19:21 we have fsosystemd for it Apr 24 13:19:32 it does the firmware loading without udev Apr 24 13:19:39 and if networking depends on wifi, you might need to populate the /dev first with udev Apr 24 13:19:52 it's already by devtmpfs Apr 24 13:21:00 but if you boot just with devtmpfs you will have no wifi at all Apr 24 13:21:50 why? Apr 24 13:21:55 cause of firmware? Apr 24 13:21:58 yes Apr 24 13:22:08 we have fsosystemd for it Apr 24 13:22:59 whenever a module requests firmware via default firmware interface in kernel fsosystemd is able to load it Apr 24 13:23:11 but if it is not module? Apr 24 13:23:22 if the wifi driver is compiled in kernel Apr 24 13:23:32 yes thats another thing ... Apr 24 13:23:38 you will never notice that the device has wifi card Apr 24 13:23:44 thats done with enabling the WiFi resource in FSO Apr 24 13:23:52 unless you start touching all the uevent files Apr 24 13:24:22 you know that the device has a WiFi card Apr 24 13:24:49 with FSO you requests the WiFi resource whenever you want to use WiFi Apr 24 13:25:17 but this is quite agains the linux philosophy - that the hardware should just work without any configuration files Apr 24 13:25:22 then there is a plugin in fsodeviced which does the steps needed to enable wifi (loading modules, sysfs-configuration, ...) Apr 24 13:25:56 it's for embedded systems to keep stuff minimal Apr 24 13:25:58 and udev is quite nicely doing this automatically - but the downside is the booting delay Apr 24 13:26:01 and just target one specific device Apr 24 13:26:07 yes Apr 24 13:26:18 that was one of the decision why this was done Apr 24 13:26:26 not saying I am happy with this Apr 24 13:26:29 oki - if this is just for one device and for given hw set it works Apr 24 13:27:16 in a lot devices you can't disable WiFi without unloading the kernel module Apr 24 13:27:25 no rfkill etc. Apr 24 13:27:41 oki Apr 24 13:28:02 btw i think udev could be quite fast if we had as many things as possible as modules Apr 24 13:28:24 because udev would not touch so many files and the /dev populating would be fast Apr 24 13:28:47 and then when you load module udev can just read it on netlink... Apr 24 13:29:15 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, ... Apr 24 13:29:30 and booting would be also faster - i think current kernel is quite big Apr 24 13:29:42 radekp: maybe Apr 24 13:29:49 you cant even flash it in nand Apr 24 13:31:29 * radekp has to go... cu Apr 24 13:34:18 radekp: cya Apr 24 13:48:02 JaMa: I get the following with latest shr and systemd: http://paste.pocoo.org/show/586502/ Apr 24 13:58:27 JaMa: and a possible but dirty fix: http://paste.pocoo.org/show/586514/ Apr 24 14:08:02 JaMa: but packaging systemd-machine-units for crespo now works as expected Apr 24 14:15:01 morphis: maybe we can set empty string in systemd-machine-units_1.0.bb Apr 24 14:15:10 instead of or "" on many places Apr 24 14:15:12 yes Apr 24 14:15:27 a better solution than what I did :) Apr 24 14:15:32 but weird I've tried to build it with palmpre (also should be empty) and it haven't failed Apr 24 14:15:47 hm Apr 24 14:17:10 let's see if it works on the device Apr 24 15:13:31 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 Apr 24 15:55:46 mrmoku: nope Apr 24 15:58:28 mrmoku: whats tinyalsa? Apr 24 16:58:03 DocScrutinizer51: some alternative libasound as well Apr 24 16:58:31 https://github.com/tinyalsa/tiny Apr 24 16:58:38 err Apr 24 16:58:43 -tiny Apr 24 17:00:35 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 Apr 24 17:01:39 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 Apr 24 17:05:13 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 Apr 24 17:20:06 fsck 14 commits to teach scons to build gpsd correctly :/ Apr 24 17:20:42 feel free to test jansa/gpsd branch Apr 24 17:21:39 * JaMa off Apr 24 17:54:02 does anybody use current shr-core on palm pre (plus)? Apr 24 17:55:10 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 Apr 24 17:55:49 I'm not sure if it's system or shr related; some people had bootup problems with webOS, too Apr 24 17:55:50 you can try shr-2012.1, but palm pre does not work with systemd Apr 24 17:56:01 ah Apr 24 17:57:39 JaMa: I installed bootr so I should see a bootloader before it "crashes"!? Apr 24 17:57:55 mrmoku: looking into it Apr 24 17:58:15 rines: I don't have any palm.. so dunno Apr 24 17:58:31 hmm.. okay; will try it again ;) Apr 24 17:58:41 but in theory bootloader should be still able to start init Apr 24 17:58:52 err kernel and kernel start init Apr 24 17:59:09 yes, but I cannot see any bootloader as well; so I think (and hope) it was palm system related Apr 24 18:01:51 ...later, as it's a PITA on N900 Apr 24 18:05:00 DocScrutinizer51: yeah better on something bigger :) Apr 24 18:14:59 indeed Apr 24 18:18:22 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 Apr 24 18:19:15 so basically 4 layers of buffers: hw, sw-phy, sw-log, and msg-lists Apr 24 18:20:10 of course IRQ driven Apr 24 18:20:42 MEH! Apr 24 18:44:10 DocScrutinizer: you have to go deeper Apr 24 19:27:03 yo! Apr 24 19:27:45 slyon: heyho Apr 24 19:28:05 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 Apr 24 19:28:05 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 Apr 24 19:28:06 i've just read in the backlog, that udev is back again. Apr 24 19:28:07 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 Apr 24 19:28:07 freesmartphone.org: 03morphis 07cornucopia * r42dc81b1181b 10/fsogsmd/tests/testsms.vala: fsogsmd: tests: adjust SMS tests for recent changes to SMS storage class Apr 24 19:28:08 freesmartphone.org: 03morphis 07cornucopia * r050dd6fa38be 10/old/ (66 files in 16 dirs): Remove old code finally Apr 24 19:28:17 slyon: I extended your lowlevel_gta04 plugin a little bit Apr 24 19:28:21 cool Apr 24 19:29:04 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 Apr 24 19:30:00 slyon: yes we should, but I don't know where too Apr 24 19:30:03 JaMa should know Apr 24 19:30:18 slyon: please write him a mail or I will tell him tomorrow Apr 24 19:30:51 morphis, yes. I'll ask jama Apr 24 19:31:48 morphis, in the lowlevel_gta04 config you're using the /dev/ttyHS_Application interface already Apr 24 19:31:55 is this intended? Apr 24 19:33:20 I didn't tested it Apr 24 19:33:27 but thats what I have from the mailinglist Apr 24 19:33:42 ttyHS_Application is created by udev Apr 24 19:33:44 yes Apr 24 19:33:51 I had the same thought as you Apr 24 19:34:06 if you don't have the rules it's (mostly) ttyHS3 Apr 24 19:34:27 I first had there ttyHS3 Apr 24 19:34:30 ok. so we just integrate the udev rules. there is one more for the vibra call motor Apr 24 19:34:38 ok Apr 24 19:34:48 do we need to adjust them for integration? Apr 24 19:34:49 I'll take care about the udev rules Apr 24 19:34:53 great Apr 24 19:35:49 i don't think we need to adjust them. but I'll adjust the fsogsmd.conf once the udev rules are in Apr 24 19:36:23 slyon: but please take care that you're using fso-autorev.inc Apr 24 19:36:41 as shr-core uses release tarballs of the FSO components now Apr 24 19:37:05 morphis, one completly different question i stumbled upon several times: what is public override string repr() used for? It's in every FSO class... Apr 24 19:37:16 ok will use fso-autorev.inc Apr 24 19:37:27 yes, that is inherited from the AbstractObject class Apr 24 19:37:37 it's part of the logging mechanism we have Apr 24 19:38:05 what can I /should I specify there? most of the time it's just "<>" Apr 24 19:38:09 as base pattern we're using as output Apr 24 19:38:34 when using the AbstractObject you have two additional members: config and logger Apr 24 19:39:06 with repr() you have the possiblity to add additional information to the logline Apr 24 19:39:11 think about a class SimMessage Apr 24 19:39:39