**** BEGIN LOGGING AT Mon May 28 02:59:58 2012 May 28 03:46:03 * PaulFertser has misread the last message, he was talking about the SDHCI driver which is a PCI controller for SD, irrelevant. May 28 03:59:57 moo PaulFertser May 28 04:02:19 DocScrutinizer51: hey hey :) May 28 04:03:22 having fun with a 'new' lenovo t500 and a virgin suse12.1 install May 28 04:04:27 at least recent konversation works as concurrent client via ZNC now :-) May 28 04:05:00 so byebye DocScrutinizer2 May 28 04:47:06 it's really incredible what a PITA you face to setup a virgin system so it meets your preferences developed and set up during >10 years on an old similar system May 28 04:48:04 that's exactly why I never understood those windows fools who re-install every 3 months May 28 09:20:38 DocScrutinizer51: they have to... those windows fools ;-) May 28 09:20:49 otherwise the system starts to crawl like hell May 28 09:21:30 * mrmoku looking into znc as an alternative to bip... May 28 09:23:41 znc is awesome May 28 09:23:57 nice clean code inside and pretty extensible May 28 09:28:39 indeed it looks very nice May 28 09:37:38 * pabs3 wants a telepathy-based bouncer May 28 09:39:33 * mrmobil wants telepathy folks to concentrate on sip enhancing instead :-P May 28 09:40:22 speaking of telepathy, does SHR use that? May 28 09:40:58 not for telephony May 28 09:41:13 pespin was working on something telepathy based May 28 09:41:36 I _wanted_ to use it for telephony May 28 09:41:37 would be nice to use the same UI for GSM and SIP May 28 09:42:13 that was the idea indeed May 28 09:43:35 * ccxCZ would rather stay away from anything based on dbus May 28 09:43:52 hehe May 28 09:44:06 whole FSO is dbus based :-P May 28 09:44:17 yeah I know May 28 09:44:18 nothing wrong with dbus May 28 09:44:44 DocScrutinizer: thinks for mentioning ZNC :-) May 28 09:44:54 well, it's better than java-based bloatware May 28 09:46:48 dbus has no place in unix-based system, it goes directly against the philosophy (also introduces whole new set of bugs, dependencies and complexity) May 28 09:47:46 ccxCZ: the problem with unix is that you can not improve it or people call you non-unix May 28 09:48:27 ccxCZ: dbus is quite an improvement over ad-hoc text based protocols over unix sockets or sending signals ("was it SIGUSR1 or SIGUSR2 this time?") to processes May 28 09:48:46 err, no May 28 09:49:46 it's not an improvement since it requires yet another library, another daemon, either of which can have different version and produce quite dangerous bugs May 28 09:50:27 ccxCZ: I fail to see why new software is such a bad thing May 28 09:50:34 it is not May 28 09:51:03 ccxCZ: but anyways, I don't really care if my system is "unix" or not May 28 09:51:07 also I never said it's bad, I said it's not adherent to unix style May 28 09:51:13 yeah and I respect that May 28 09:51:41 ccxCZ: yeah but why should you adhere to unix style? May 28 09:52:34 ccxCZ: of course they had good ideas but they also worked in an environment that is quite different from what we have nowadays May 28 09:52:49 isolated components communicating via well defined channels make system robust and extensible May 28 09:53:42 ccxCZ: but dbus is a well defined channel May 28 09:53:47 hahahaha May 28 09:54:00 well yeah until they change it again May 28 09:54:01 and I think it is extensible too May 28 09:54:06 ccxCZ: when was it changed last time? May 28 09:55:34 very strang thing happen, I cann't off the initramfs anymore, even using the images can off it ib the past May 28 09:55:55 the reference implementation? well there were quite a few bugs because it few months ago I think May 28 09:56:01 not watching it closely May 28 09:56:04 ccxCZ: bugs of course yse May 28 09:56:22 they are almost always inevitable May 28 09:56:26 no May 28 09:57:41 why introduce bloated overengineered library, which does change and break things, to your code, instead using simple (eg. linebased) protocol when it completelly suffices? May 28 09:58:24 ccxCZ: why implement a new protocol for every service? May 28 09:58:35 ccxCZ: you need to have parsers for all these custom linebased protocols too May 28 09:58:48 ccxCZ: and often there is no software to analyze the traffic May 28 09:59:26 for well designed protocols the parsers are easy May 28 09:59:29 ccxCZ: also most linebased protocols don't support async replies, to support those you need to add some sort of request identifiers May 28 09:59:40 ccxCZ: pretty soon you have something as complex as IMAP there May 28 10:00:06 imap is pretty awful, as is irc May 28 10:00:16 ccxCZ: you also need to implement custom authentication mechanisms for each service May 28 10:00:24 wat May 28 10:00:45 I thought we were talking about ipc May 28 10:00:55 ccxCZ: yeah but you need authentication there too May 28 10:00:57 or you have serious case of dbus usage over the internet? May 28 10:01:01 ccxCZ: no, local system May 28 10:01:16 what's wrong with unix sockets? May 28 10:01:17 ccxCZ: like checking if a user has the privileges to mount a usb stick May 28 10:01:31 ccxCZ: you can't revoke permissions on unix sockets easily, if you open it you can keep it opened May 28 10:01:56 ccxCZ: I'm sure you know the limits of unix pretty well May 28 10:03:23 it is a nice system surely but does not work for all cases May 28 10:03:31 never claimed that May 28 10:03:40 and I think the best solution is to extend it May 28 10:04:12 this way you can still continue using your linebased protocols if you want May 28 10:04:15 * pabs3 wonders when Linux will get multicast sockets (to replace dbus) May 28 10:04:36 pabs3: dbus is bit more than that :) May 28 10:05:14 I expect so May 28 10:08:35 well, in my eyes dbus really hurts the extensibility, not improves it. but I won't prevent you from using it May 28 10:08:45 ccxCZ: another horrible line based protocol is the AT command set that I still have to use on my openmoko, I hate it really much :) May 28 10:09:20 I never equaled line-based with good ;-) May 28 10:09:39 * pabs3 wonders if osmocom folks will implement AT or use something else May 28 10:09:42 ccxCZ: there are actually three parallel channels to the GSM chip so that you can configure one of the channels to be dedidacted to unsolicited messages (about the same as dbus signals) May 28 10:09:43 yeah, there are plethora of bad protocols, binary and text May 28 10:10:07 pabs3: AT might be important in the non-free world for compatibility but I really hope they don't do that :) May 28 10:10:29 lindi-: do you know any nice alternative for it? May 28 10:10:31 ccxCZ: can you recommend some good line based protocol? May 28 10:10:36 PaulFertser: for AT? May 28 10:10:44 lindi-: yep May 28 10:10:53 PaulFertser: I only have this one gsm chip May 28 10:10:58 PaulFertser: no experience on other chips May 28 10:11:36 lindi-: at really sucks, but it looks like other protocols used in the field suck too. May 28 10:11:52 * pabs3 proposes dbus ;) May 28 10:12:14 PaulFertser: well at least I'd like to have a clear way to see what line is a reply to a request and which request it was May 28 10:12:36 ccxCZ: multiline replies in the context of unsolicited messages are fun :P (not) May 28 10:12:41 lindi-: indeed! May 28 10:12:48 syslog isn't that bad. VT-based terminals are more on the sucky side but still bearable May 28 10:13:29 hmm, gopher? :] May 28 10:14:44 oh and psyc seems good to me, much better than the almost-xml abomination May 28 10:14:47 * ccxCZ -> lunch May 28 10:15:16 ccxCZ: haven't looked at syslog protocol before, is it only oneway? May 28 10:15:38 yup, basically just message May 28 10:15:43 searching for "reply" in the RFC does not find anything May 28 10:15:57 ccxCZ: well that is quite easy use case May 28 10:16:07 it's more like a file format since there is no interactivity May 28 10:16:51 anyway I'm off for the moment May 28 10:17:34 ok May 28 10:43:51 lindi-: believe it or not, the STE LTE chip I'm working for has still AT as only control interface May 28 10:44:57 sigh May 28 10:45:04 and I'd dare to say the android RIL developters are quite happy about tHAT May 28 10:47:22 after all AT is standard according to 3GPP May 28 10:49:58 But it lacks too many features and all those 3gpp docs are so obscure that the actual devices are never compatible or sane. May 28 10:50:21 http://lxr.free-electrons.com/source/drivers/net/caif/caif_hsi.c is what you got underneath, and a "standard" RIL on top, quite similar to https://github.com/aferre/u300-ril May 28 10:51:07 ccxCZ, wow, finally one other person who doesn't like dbus and noticed that this is not really unix-way =) May 28 10:51:46 dbus is bullshit, really May 28 10:52:36 but alas it seems it's the only available "standard" May 28 10:53:27 PaulFertser: what are the lacking features ot AT ? May 28 10:54:15 I tned to agree 3GPP AT at large docs are a PITA May 28 11:09:23 DocScrutinizer51: i can't tell you the list now but the amount of non-standard commands in every gsm device i touched was really too big. May 28 11:11:33 hmm, there are like a dozen in every second one, yes. That's caused by 3GPP not caring about stuff like engineering mode, and other not strictly CALL related stuff May 28 11:12:41 or getting time from the GSM network May 28 11:13:02 (we still don't know how to do that on freerunner) May 28 11:13:32 lindi-: it looks like too few network support it anyway. May 28 11:14:13 PaulFertser: hard to say, I only know that they do here in Finland May 28 11:15:02 nowadays time over GSM is a almost mandatory feature, but yes it seems there's no widespread commonly adhered standard May 28 11:15:34 things like AT%POWEROFF not being in 3GPP is bewildering May 28 11:17:12 and generally AT is a awfull ugly braindamaged protocol without any transaction coherence, invented in a time when Hayes sold modems^H accoustic couplers May 28 11:19:28 lindi-: that's something that always amazed me, that phone could not get the time by the network May 28 11:19:33 lindi-: FSO has some handling for GSM time, doesn't it work the way it's expected? May 28 11:19:44 if however they finally would make up their mind and spend a unique sequence number transaction identifier to each command and response... May 28 11:19:49 PaulFertser: it's only for timezone May 28 11:20:38 Oh May 28 11:20:50 lindi-: nope May 28 11:21:10 * mrmoku is old enough to have had fun with such a 300 Baud accoustic coupler :-) May 28 11:21:17 afaik it *may* get actual TOD from GSM May 28 11:22:47 DocScrutinizer51: I haven't heard of anybody reporting success May 28 11:23:33 * DocScrutinizer51 seems to have heard though May 28 11:23:52 well if you find some report then I'd like to hear about it May 28 11:24:09 here it always just starts from zero when the modem is powered up May 28 11:29:24 freesmartphone.org: 03morphis 070.11 * reab5312f9c12 10cornucopia/fsogsmd/src/lib/Makefile.am: fsogsmd: lib: include missing fsogsm3rdparty.vapi/.deps files for distribution May 28 11:29:24 freesmartphone.org: 03morphis 070.11 * r86f1101dbb6c 10cornucopia/fsogsmd/src/lib/Makefile.am: fsogsmd: lib: pack fsogsm-2.0.deps file into our distribution package too May 28 11:29:24 freesmartphone.org: 03morphis 070.11 * r96825ac0023c 10cornucopia/fsogsmd/ (ChangeLog configure.ac): fsogsmd: release version 0.11.2 May 28 11:34:28 lindi-: I think it's an unsol msg that may differ in format from network to network, and it's not exactly sent twice a second May 28 11:35:35 DocScrutinizer51: I see timezone updates like that May 28 11:36:13 and yeah, nowadays it's quite possible that most devices/modems rely on time via ~gsm-agps rather than the original timestamp message May 28 13:10:26 http://lists.maemo.org/pipermail/maemo-developers/2012-May/028899.html May 28 14:09:34 freesmartphone.org: 03morphis 07specs * r6fe4f43495e2 10/configure.ac: Keep version in sync with libfso-glib May 28 14:12:28 SHR: 03Martin.Jansa 07meta-smartphone * re7118b83a30e 10/meta-fso/recipes-freesmartphone/freesmartphone/fso-specs_git.bb: fso-specs: bump SRCREV to get matching version with libfso-glib May 28 14:45:38 GNUtoo-desktop today test very bad, fbset -x --test result can't work May 28 14:46:00 and suddenly, the same image, but initramfs will be loaded May 28 14:46:18 and I don't know how to off it anymore May 28 14:49:20 any idea? btw, can I use email to communite, i am not sure my mother won't cut up network before I met you May 28 14:56:17 hi May 28 14:57:23 what do you mean by "the same image" May 28 15:00:19 yes, the same May 28 15:00:40 I don't change the boot image May 28 15:01:06 but suddenlty, it will load the initramfs May 28 15:02:29 even the image whose kernel without config_vt will load initramfa May 28 15:02:46 but I am not usre whether it is power line problem May 28 15:06:30 GNUtoo-desktop can you know now May 28 15:29:23 lindi-: hi, i think old openmoko images where able to get the time from GSM network. It worked before i switched to SHR May 28 15:34:57 hmmm May 28 16:14:44 freesmartphone.org: 03morphis 07cornucopia * r5fd28af3f768 10/fsogsmd/conf/GTA04/fsogsmd.conf: fsogsmd: conf: GTA04: don't try load not available plugin pdp_option_gtm601 anymore May 28 16:14:44 freesmartphone.org: 03morphis 07cornucopia * r86f130b875c4 10/fsogsmd/src/lib/Makefile.am: fsogsmd: lib: include missing fsogsm3rdparty.vapi/.deps files for distribution May 28 16:14:45 freesmartphone.org: 03morphis 07cornucopia * r75c5010ea067 10/fsogsmd/src/lib/Makefile.am: fsogsmd: lib: pack fsogsm-2.0.deps file into our distribution package too May 28 16:14:45 freesmartphone.org: 03morphis 07cornucopia * r1aea1b0fce24 10/libgsm0710mux/Makefile.am: libgsm0710mux: respect ABI version when building library May 28 17:26:05 freesmartphone.org: 03morphis 07cornucopia * r464fbdb3a2bc 10/tools/mdbus2/src/Makefile.am: tools: mdbus2: don't mention gio-2.0 as required twice May 28 17:26:06 freesmartphone.org: 03morphis 07cornucopia * rd74538e1b096 10/tools/mdbus2/ (ChangeLog configure.ac): tools: mdbus2: switch to release mode for 2.2.0 release May 28 17:26:07 freesmartphone.org: 03morphis 07cornucopia * r0e453db1fb13 10/tools/mdbus2/configure.ac: tools: mdbus2: post release work May 28 18:10:35 nschle85: I read the source code of those but never found anything related May 28 18:26:18 nschle85 has quit it seems **** ENDING LOGGING AT Tue May 29 02:59:58 2012