**** BEGIN LOGGING AT Tue Jul 14 02:59:57 2009 Jul 14 05:25:41 DocScrutinizer, I have no idea about ramconsole and its state Jul 14 05:44:59 is it possible to have an optional argument in vala? something like "int function (int argument1, int argument2 = 42)" so that if argument2 is used ok, else it is used with the 42 value Jul 14 05:48:19 mrmoku: read the bug report Jul 14 06:26:58 DocScrutinizer: we have problems with some headsets even without EEPROM switching. Jul 14 06:27:42 DocScrutinizer: the drivers are about the same because HCI interface seem to be standardised. But yes, chip difference is most probably what matters here. Jul 14 06:28:13 DocScrutinizer: the question is: how do we know for sure it's not BT firmware problem and how to find a decent workaround not being a BT hacker? Jul 14 07:09:00 is there anyone who know vala and can answer 2 really simple questions? Jul 14 07:09:53 1 how can i get the system time? (something like time()) 2 is it possible to have an optional argument in vala? thanks :D Jul 14 07:25:14 any ideas on what's going on with the latest shr? Jul 14 07:25:42 i updated my packages via opkg update && opkg upgrade and dbus seems to be broken Jul 14 07:29:13 tomboy64: "dbus broken" is not exactly specific description Jul 14 08:08:47 SHR: 03seba.dos1 07shr-installer * rf95edf215e46 10/shr-installer: Add temporiary debug option. Will be replaced by configuration system. Jul 14 08:08:57 SHR: 03seba.dos1 07shr-installer * rc61d578a95d9 10/shr-installer: Some cosmetic changes. Jul 14 08:08:58 SHR: 03seba.dos1 07shr-installer * r2de88ec0eab1 10/shr-installer: Make Dialog class, instead of just functions. Jul 14 08:18:26 SHR: 03seba.dos1 07shr-installer * rce2e83a66f72 10/shr-installer: Partialy implement upgrade. Commented now due to PackageKit bug, which causes infinite loop of "skipping duplicate" messages. Jul 14 08:34:02 excuse me: what is the package joe in unstable repo? Jul 14 08:40:36 * TAsn-moko is bored Jul 14 08:41:13 ciao Jul 14 08:44:02 good morning Jul 14 08:44:21 'llo all Jul 14 08:44:28 morning Jul 14 08:44:50 * pbaxter likes a lot 'Red Hot Chili Peppers' Jul 14 08:48:53 * dos1 shouts "dream of califoooornicaaaaatioooooon" ;D Jul 14 08:50:02 dos1: have you ever seen the video of californication in rio? Jul 14 08:50:57 dos1: http://www.youtube.com/watch?v=K84iT_8G-AU Jul 14 08:51:05 watch only the first 3 mins dos1 Jul 14 08:51:07 it's wonderful Jul 14 08:51:12 Flea reach his best Jul 14 08:54:04 pbaxter: I prefer : http://www.redhotchillipipers.co.uk/ :) Jul 14 08:55:35 tig| what is there? Jul 14 08:56:56 pbaxter: a bagpipe group that play rock songs :) Jul 14 08:59:20 tig| : red hot are all but not only rock Jul 14 09:15:44 SHR: 03seba.dos1 07shr-installer * r07e6691a2250 10/shr-installer: Add stup for installing packages. Jul 14 09:16:18 stub* Jul 14 09:16:19 ... Jul 14 09:19:22 when i try to use mokonnect i receive this error Jul 14 09:19:23 http://pastebin.ca/1494496 Jul 14 09:19:26 can someone help me?+ Jul 14 09:22:58 pbaxter, no error.. .just warning Jul 14 09:23:29 mrmoku: and to make it work? Jul 14 09:23:36 it says me: Jul 14 09:23:58 could not find ethernet in connman devices Jul 14 09:24:07 could not find wifi in connman devices Jul 14 09:24:23 current profile is unknown, select a profile or save a new one Jul 14 09:24:26 now??? Jul 14 09:25:05 start wifi and restart connman afterwards Jul 14 09:25:15 it does not get it when turning on wifi after connman is started Jul 14 09:25:26 how to start connman? Jul 14 09:25:30 gui or terminal? Jul 14 09:26:02 pbaxter, don't know if you can do it via shr-settings Jul 14 09:26:10 /etc/init.d/connmand restart Jul 14 09:26:12 should work Jul 14 09:26:16 I think Mokoconnect should start Wifi und restart connman on it's own Jul 14 09:26:32 so? Jul 14 09:26:34 what do i do? Jul 14 09:28:24 mrmoku: it doesn't work Jul 14 09:28:28 it says same things Jul 14 09:29:19 Heinervdm, and I think damn connmand should just recognize that wifi got started ;) Jul 14 09:29:24 as it did some time ago Jul 14 09:30:00 mrmoku: yes that would be better, but even then mokoconnect should start Wifi Jul 14 09:30:02 wifi works now Jul 14 09:30:06 i can with mokonnect Jul 14 09:30:25 but if i put a /etc/init.d/connman restart before the start of mokonnect...is it stupid or not? Jul 14 09:31:10 Heinervdm, yeah, it should probably start Wifi, but only if you select a profile that is configured with wifi Jul 14 09:31:34 yes Jul 14 09:31:39 a sec...i'm trying with my wpa connection Jul 14 09:33:48 got to go and pickup junior from the kindergarten.... bbl Jul 14 10:30:59 ~seen quickdev Jul 14 10:30:59 bumbl: i haven't seen 'quickdev' Jul 14 10:31:12 ~seen Dave Jul 14 10:31:12 dave was last seen on IRC in channel #openmoko-cdevel, 88d 21h 10m 18s ago, saying: 'dos1, I thought opimd was just a legend!? :o'. Jul 14 10:33:14 bumbl, never give up ;) Jul 14 10:45:15 mrmoku: ;) Jul 14 10:53:11 for some reason shr settings says i have v5 and moko8... weird! i thought i have v6 moko9 Jul 14 10:53:55 TAsn-moko: shr-settings says, what hardware revision do you have? Jul 14 10:53:57 where? Jul 14 10:54:34 * dos1 have v5 moko11 :P Jul 14 10:54:44 has* Jul 14 10:54:53 modem info said v5 Jul 14 10:55:30 modem knows about hardware revision? Jul 14 10:55:39 * dos1 checks what it says to him Jul 14 10:56:26 i have just moko11b1 and GTA01/GTA02, but it has been changed in recent firmwares IIRC Jul 14 10:56:51 sounds stupid, misread it Jul 14 10:57:09 probably Jul 14 10:57:46 should i upgrade to moko11? Jul 14 10:58:44 TAsn-moko: definetely Jul 14 10:59:23 what will i gain? Jul 14 10:59:24 dos1: and yes, for some reason older gsm firmware versions included gta0X version too, but it made zero sense and was removed. Jul 14 10:59:42 TAsn-moko: stable phone :P Jul 14 11:00:11 TAsn-moko: compatibility with all SIM cards, hardware flow control support (avoid overruns) and more reliable wakeup (though there's a kernel workaround there already). Jul 14 11:00:32 my phone is stable Jul 14 11:00:51 paul: cool Jul 14 11:00:59 thanks Jul 14 11:01:02 ciao Jul 14 11:33:41 mrmoku: building newer packagekit is now on higher priority - version which we already have has bug when requesting upgradable packages list Jul 14 11:33:46 mrmoku: it goes into infinity loop Jul 14 11:34:04 dunno if it's fixed now, i'll check commit log Jul 14 11:38:42 <|Leto|> PaulFertser: i receive only this message: dbus is broken, dbus is borked Jul 14 11:38:46 <|Leto|> dbus is started though Jul 14 11:38:59 <|Leto|> this happens both when i do opkg upgrade in SHR Jul 14 11:39:13 <|Leto|> and in the gentoo i installed on my sd-card Jul 14 11:39:43 |Leto|: you can try to start dbus daemon manually and to increase loglevel etc Jul 14 11:40:01 <|Leto|> well, dbus is running, in both systems Jul 14 11:40:07 <|Leto|> that's what's so weird about it Jul 14 11:40:10 <|Leto|> but i'll try Jul 14 11:44:20 |Leto|: dbus? Jul 14 11:44:32 <|Leto|> dos1: ack Jul 14 11:44:32 |Leto|: check, if frameworkd is started... Jul 14 11:44:37 not dbus... Jul 14 11:44:42 <|Leto|> mmmkay Jul 14 11:44:43 * dos1 really have to change that messages Jul 14 11:44:52 has* Jul 14 11:44:57 ghrrr Jul 14 11:53:51 * |Leto| falls asleep while he gitclones openmoko's kernel tree Jul 14 11:56:27 |Leto|, have you ever tried "git clone git://the.internet" that is really long :D Jul 14 11:57:06 * |Leto| gitclones m0nt0 Jul 14 11:57:11 <|Leto|> wow! that went fast :-D Jul 14 11:57:17 lol Jul 14 12:10:38 where's the hw revision of my moko is written at? Jul 14 12:11:13 I have both the original box and the moxo Jul 14 12:11:16 moko* Jul 14 12:11:41 there's a certain /proc var you can print to get the exact. Jul 14 12:11:47 but try /proc/cpuinfo first Jul 14 12:11:53 check Revision:.. Jul 14 12:12:01 Revision: 350 is gta02 a5 Jul 14 12:12:09 360 is a6 (or a7) Jul 14 12:12:13 this is on the wiki Jul 14 12:13:21 TAsn_, cat /sys/devices/platform/neo1973-version.0/pcb Jul 14 12:13:33 thanks Jul 14 12:13:46 0x001 ? Jul 14 12:13:53 TAsn_: yes, that's A6 Jul 14 12:14:01 TAsn_: raw values from the board Jul 14 12:14:09 so I wonder why the modem says V5 ;) Jul 14 12:14:22 TAsn_: the modem has zero idea, it just lies. Jul 14 12:14:44 damn modem Jul 14 12:14:46 they are all alike Jul 14 12:14:51 modems* Jul 14 12:15:06 thanks :) Jul 14 12:16:28 PaulFertser: is the modem upgrading risky/time consuming/annoying? :) Jul 14 12:17:02 TAsn_: no/no/no IMHO Jul 14 12:17:10 cool Jul 14 12:17:13 will do :) Jul 14 12:17:21 (brb with moko11) Jul 14 12:19:47 TAsn_: just untar an image to µsd and boot it and you are done Jul 14 12:20:20 PaulFertser: did anything change between moko11beta and moko11 iirc not but just to make sure? Jul 14 12:20:30 bumbl: exactly nothing except the "b" letter. Jul 14 12:22:47 :) Jul 14 12:23:56 bumbl: does the original 512 usd suffices? Jul 14 12:26:37 TAsn_: yes Jul 14 12:26:44 cool :))) Jul 14 12:26:49 mickeyl: hello Jul 14 12:26:53 TAsn_: stop trolling. You should have seen recommendation to upgrade modem-FW several times here now ;-) Jul 14 12:26:54 PaulFertser: hmm i might reflash then XD Jul 14 12:27:02 * TAsn_ is excited about bricking his moko :) Jul 14 12:27:07 well anyway have a nice day Jul 14 12:27:09 DocScrutinizer: ^ Jul 14 12:27:19 mickeyl: could you recall me the ftp address for sources.fs.o ? Jul 14 12:27:43 hum damn I'm stupid Jul 14 12:27:47 :p Jul 14 12:28:01 can the std. nor boot not boot from microsd ? Jul 14 12:28:32 I'm thinking about updating using a 16gb sdhc card Jul 14 12:28:44 using the update image recommended method Jul 14 12:28:49 FiXion_: nor u-boot probably will not be able to boot from SDHC Jul 14 12:29:10 FiXion_: but you can try your NAND bootloader, should work too. Jul 14 12:29:28 so I need to install qi bootloader? Jul 14 12:29:36 FiXion_: no Jul 14 12:30:00 std- NAND uBoot bootloader can boot from sd Jul 14 12:30:02 TAsn_: I think I stated on wiki there's absolutely no chance to break anything by aplying my uSD-image for modem-update Jul 14 12:30:18 DocScrutinizer: you have Jul 14 12:30:19 :) Jul 14 12:30:27 ok, I admit it, I'm a troll. ;) Jul 14 12:31:06 mrmoku, playya, mickeyl: OK there is a new release here: http://www.freesmartphone.org/sources/vala-0.7.5-fso1.tar.gz Jul 14 12:31:20 mrmoku, playya, mickeyl: this is up to date with gnome Jul 14 12:31:23 ptitjes_, with async libfso? ;) Jul 14 12:31:42 mrmoku, playya, mickeyl: this does not include checks for dbus enumeration strings Jul 14 12:32:03 mrmoku, playya, mickeyl: but this does include dbus async fixes almost for the client part for now Jul 14 12:32:32 mrmoku, playya, mickeyl: thus I can generate "yields" keywords for dbus methods Jul 14 12:32:52 mrmoku: I'll commit the code for vala-dbus-binding-tool right now Jul 14 12:33:01 nice :) Jul 14 12:33:05 FiXion_: you may get unexpected *color-scheme* when booting from NAND, but other than that there should be no issues with NAND-*uBoot*. Qi won't work for uSD-GSM-flashing Jul 14 12:33:36 ok. how to I tell NAND uboot to boot from sd ? Jul 14 12:33:57 FiXion_: bot to uBoot-menu Jul 14 12:34:11 I have no idea how to do that Jul 14 12:34:17 FiXion_: select "boot from uSD (ext2/vfat)" Jul 14 12:34:19 I've only ever used nor boot menu Jul 14 12:34:25 FiXion_: by pressing aux Jul 14 12:34:38 so power first -when the openmoko splash is shown.. press aux Jul 14 12:34:42 FiXion_: when menu item is highlited, press power Jul 14 12:34:44 freesmartphone.org: 03ptitjes 07vala-dbus-binding-tool * r6071da6ad645 10/src/vala-dbus-binding-tool.vala: Jul 14 12:34:44 freesmartphone.org: Merge parameters and throws iteration loop Jul 14 12:34:44 freesmartphone.org: Signed-off-by: Didier 'Ptitjes Jul 14 12:34:45 FiXion_: no, before splash Jul 14 12:34:45 freesmartphone.org: 03ptitjes 07vala-dbus-binding-tool * re643288710e2 10/src/vala-dbus-binding-tool.vala: Jul 14 12:34:49 freesmartphone.org: Add yields for dbus async methods Jul 14 12:34:51 freesmartphone.org: Signed-off-by: Didier 'Ptitjes Jul 14 12:34:57 I hold in aux and then press power - to get to nor boot menu Jul 14 12:35:05 mrmoku: see you got it ^^^^^ Jul 14 12:35:23 FiXion_: hold power and then immediately aux to get into NAND boot menu Jul 14 12:35:30 FiXion_: NAND: press power, after 1sec press and hold aux Jul 14 12:35:38 and press both until in appears Jul 14 12:35:45 mrmoku: so to use that from C Jul 14 12:35:48 ok.. I'll try that. Jul 14 12:35:49 thanks Jul 14 12:36:00 <|Leto|> i want to compile my own kernel from the openmoko sources. i cloned the tree, but when i try to run the build-script, i get: Jul 14 12:36:05 <|Leto|> There is no branch in the local copy of the repository right now! Jul 14 12:36:07 <|Leto|> Hint: type git-branch, make sure you are in a valid branch and then try again Jul 14 12:36:26 <|Leto|> typing "git branch" says *(no branch) and master Jul 14 12:36:49 <|Leto|> though i did "git checkout andy-tracking" before Jul 14 12:37:54 PaulFertser: I wonder if old uBoot could boot from a SDHC which is formated and holds partitonsize of a 256MB uSD Jul 14 12:38:49 PaulFertser: to be verbose: Is it a hw-issue that makes SDHC fail, i.e. a different protocol and SDHC isn't capable to speak ld prot? Jul 14 12:39:10 s/ ld/ old/ Jul 14 12:39:10 DocScrutinizer meant: PaulFertser: to be verbose: Is it a hw-issue that makes SDHC fail, i.e. a different protocol and SDHC isn't capable to speak old prot? Jul 14 12:40:45 mrmoku: just create the proxy as you were before and call the async functions defined in freesmartphone.h Jul 14 12:43:18 PaulFertser: (BT: we have problems with some headsets) which op-mode? I don't see any simple way to test for driver-vs-fw bugs for our screwed OM-special-mode (GSM-BT) Jul 14 12:43:44 btw. why do I have to press power for ~5-8 seconds before it powers on? Jul 14 12:44:17 PaulFertser: for standard A2DP and SCO-over-usb the test is obvious: attach a USB interface to the FR-BT-module and hok up to a laptop Jul 14 12:45:19 DocScrutinizer: SDHC uses different units for addressing, so no hw problems but to access it software support must be present. Jul 14 12:45:41 DocScrutinizer: (attach to laptop) i'm afraid the result will be the same. Jul 14 12:46:09 FiXion_: u-boot source says 1 second. /* That many seconds the power key needs to be pressed to power up */ #define POWER_KEY_SECONDS 1 Jul 14 12:46:15 DocScrutinizer: i tell you i had two different headsets, one fully worked and one (more modern) worked but gave no sound. With exactly the same hardware and software. Jul 14 12:46:32 FiXion_: hmm, wrong define Jul 14 12:46:59 DocScrutinizer: and i just can't understand wtf we're not supposed to receive any help from BT module vendor. It's their firmware after all! Jul 14 12:47:15 I only know that every time I need to turn the phone no - it have to hold it for "a really long time" Jul 14 12:47:28 and I can't hold it in - to forcefully shut it down. Jul 14 12:47:40 annoying when the om2009 does not have a "shutdown" button Jul 14 12:47:52 so either I pull the battery or open a terminal and enter shutdown -h now Jul 14 12:47:58 or I suppose I could just write halt Jul 14 12:48:02 but still Jul 14 12:48:05 PaulFertser: I'm not saying we're not supposed to, just say I have no idea what's the situation and who is the man with the hat on at heir side and at OM's Jul 14 12:49:32 DocScrutinizer: i feel like our problems are somewhat deep, probably if we can ask one of bluetooth hackers to investigate it (and give them hardware) they'd tell something. I'm not sure there're many people who understand that sco thing (and i know holtmann have looked at my logs and didn't see anything wrong with them). Jul 14 12:50:20 PaulFertser: bumbl: Thanks ;) I'm now a moko11 user :) Jul 14 12:50:48 ptitjes_, great, thanks Jul 14 12:50:51 DocScrutinizer: if we can make sco-over-usb work we could at least forward the data from gsm to cpu to usb to bt Jul 14 12:51:01 will try that after getting the testing image done Jul 14 12:51:12 otherwise TAsn_ will be very angry with me ;) Jul 14 12:51:13 DocScrutinizer: knowning that programs always have bugs it's quite possible that our BT chip has some buggy firmware version not compatible with modern headsets. Jul 14 12:51:18 DocScrutinizer: adds latency for sure but it could still be better than nothing Jul 14 12:51:30 mrmoku: hehe :))) Jul 14 12:51:38 mrmoku: :p Jul 14 12:51:40 mrmoku: I know you think the same as me about this topic Jul 14 12:51:47 (the importance of a solid testing image) Jul 14 12:51:47 btw Jul 14 12:52:14 #551 Jul 14 12:52:21 I think we should add my hackish fix Jul 14 12:52:25 until we get it fixed for real Jul 14 12:52:33 (i.e add the sleep 3 to the init script) Jul 14 12:52:43 as it's still broken with last update Jul 14 12:52:49 and that's BAD for the users ;\ Jul 14 12:53:08 <|Leto|> nobody willing to help me change the kernel branch to something usable? Jul 14 12:53:30 <|Leto|> i know i got it working on my laptop a few months back :-/ Jul 14 12:53:52 |Leto|: just do the same as you did then! (read: I have no clue, sorry) Jul 14 12:54:10 <|Leto|> i think i did :-D Jul 14 12:54:19 lindi-: I think I know for sure there were positive reports of SCO-via-PCM Jul 14 12:54:19 * |Leto| swears on git Jul 14 12:54:34 DocScrutinizer: OM bought like 20000 of those modules. I think it'd be fair to expect the vendor to provide some support. Jul 14 12:54:47 DocScrutinizer: sure, i had SCO-via-PCM working Jul 14 12:54:59 DocScrutinizer: as well as Jan Jul 14 12:55:07 DocScrutinizer: and probably several other folks. Jul 14 12:55:24 DocScrutinizer: yes with some headsets Jul 14 12:55:35 DocScrutinizer: it seems to depend on which headset you have Jul 14 12:55:37 PaulFertser: (it'd be fair) Sure. So what do you expect me to say now? Jul 14 12:55:51 |Leto|: you did it wrong. you should have done "git checkout -b andy-tracking origin/andy-tracking" Jul 14 12:55:57 DocScrutinizer: not many people know they need to patch hciconfig to use sco-via-pcm Jul 14 12:56:05 DocScrutinizer: sorry, sco-over-usb Jul 14 12:56:19 DocScrutinizer: i don't know. Jul 14 12:56:43 lindi-: patching hciconfig is quick hack, i think there exists some more clean way. Jul 14 12:57:03 * |Leto| shrugs Jul 14 12:57:09 <|Leto|> pebcak Jul 14 12:57:11 i'd be happy to just have sco-via-usb work :) Jul 14 12:57:12 mrmoku: got anything to say about what I said? :) (adding quick hack fix to #551) Jul 14 12:57:12 <|Leto|> thanks PaulFertser Jul 14 12:57:24 PaulFertser: lindi-: [2009-07-14 14:43:18] PaulFertser: (BT: we have problems with some headsets) which op-mode? Jul 14 12:57:31 lindi-: and for me working headset worked both with sco-over-hci (after patching) and with sco-over-pcm. Non-working headset didn't work both ways too. Jul 14 12:57:54 DocScrutinizer: it doesn't matter how to transfer SCO. It just didn't work in both modes (over HCI and over PCM). Jul 14 12:58:13 <|Leto|> PaulFertser: the instructions on the openmoko-kernel-page are wrong then. would you mind changing it? ( http://git.openmoko.org/?p=kernel.git;a=summary ) Jul 14 12:58:36 PaulFertser: I have problems with your questions Jul 14 12:59:13 |Leto|: i can't. Moreover developers are supposed to know git at least a bit. Jul 14 12:59:41 PaulFertser: I barely know git :) Jul 14 12:59:55 and that's a BIG shame Jul 14 13:00:01 because git rocks Jul 14 13:00:04 TAsn_: as I... Jul 14 13:00:07 and i agree Jul 14 13:00:08 <|Leto|> i'm no developer Jul 14 13:00:16 I can only do the basics and I can get around Jul 14 13:00:19 <|Leto|> and i still want a current kernel Jul 14 13:00:20 lindi-: PaulFertser: I really can't start to think about which might be the failure-patern if it seems not even you both agree on what is the problem Jul 14 13:00:22 I'm no git jedi though Jul 14 13:00:24 <|Leto|> am i a pariah now? Jul 14 13:00:27 DocScrutinizer: I'm not sure i was asking questions... More like i wanted to say that it'd be nice and fair to get some support from the manufacturer as it's their responsibility to ensure correct module<->bluez4 operation. Jul 14 13:00:31 |Leto|: current kernel is in shr-unstable Jul 14 13:00:43 <|Leto|> dos1: it won't boot with my gentoo Jul 14 13:00:48 |Leto|: why? Jul 14 13:00:56 it's just kernel Jul 14 13:00:59 PaulFertser: I agree Jul 14 13:01:01 lindi-: i thought we have the same impression about BT SCO problems, right? Jul 14 13:01:02 the same for many distros :P Jul 14 13:01:33 |Leto|: just make sure modules are in correct place Jul 14 13:02:16 <|Leto|> dos1: apparently it has something to do with parts of my system that i built against differently configured sources (my guess) Jul 14 13:02:33 PaulFertser: in your first statement I don't read even SCO Jul 14 13:02:46 ptitjes, what was the name of the prolog like language you mentioned @ fsoshrcon? Jul 14 13:03:24 TAsn_, try to start dbus earlier instead, maybe? Jul 14 13:03:30 |Leto|: i don't think so Jul 14 13:03:51 Flora Jul 14 13:03:56 XSB ? Jul 14 13:03:57 <|Leto|> taking a closer look it's trying to find stuff on a wrong partition Jul 14 13:04:01 * |Leto| hangs his head in shame Jul 14 13:04:25 F-Logic or sth similiar. maybe flora Jul 14 13:04:44 mrmoku: that's reasonable enough ;) Jul 14 13:04:57 mrmoku: though that's also racy Jul 14 13:05:06 we need to fix ophonekitd :) Jul 14 13:05:30 which reminds me Jul 14 13:05:43 Ainulindale: did you fix the makefile for creating an OE env? Jul 14 13:06:00 DocScrutinizer: i thought that when i talk about BT problems i imply SCO as we seem to not have any other kind of problems with it :) Jul 14 13:06:38 mrmoku: btw, when you are done creating the image, please announce in SHR-blog and shr-user about the new change :) (i.e updating testing regulary) Jul 14 13:07:16 PaulFertser: that's a pita as I dunno what you assume you seem to have Jul 14 13:07:33 DocScrutinizer: sorry Jul 14 13:07:33 TAsn_, nah... you should do that ;) Jul 14 13:07:55 mrmoku: bah. Jul 14 13:07:58 ok ;\ Jul 14 13:08:09 though if I fail calculus it'll be on your concious :) Jul 14 13:08:32 *conscience Jul 14 13:10:19 mrmoku: anyhow, I'm off to study a bit more, please let me know when you got a working image. Jul 14 13:10:25 and please try to make dbus load faster. Jul 14 13:11:06 TAsn_, yeah, will take a look Jul 14 13:11:09 (sooner) Jul 14 13:11:19 though I'm off for some daywork first :P Jul 14 13:11:27 mrmoku: sure thing :) Jul 14 13:11:28 have fun. Jul 14 13:12:23 TAsn_, things are different ;) Jul 14 13:12:31 I relooked at your log in the ticket Jul 14 13:12:37 it is *not* that dbus is not started Jul 14 13:12:59 I also need to review my log as I don't remember by heart :) Jul 14 13:13:34 Will take a look at ophonekitd / lfg code later Jul 14 13:14:17 mrmoku: cool :) Jul 14 13:14:19 thanks. Jul 14 13:14:20 ciao. Jul 14 13:16:26 I am happy to report that I have just undated opkg then run an upgrade from 3rd July to current and no segfaults :) great job everyone :) :) :) Jul 14 13:18:01 aaah Jul 14 13:18:06 ~update Jul 14 13:18:07 [update] opkg update; opkg install opkg; opkg upgrade Jul 14 13:18:40 tig|: :) Jul 14 13:18:43 DocScrutinizer: lol ;) Jul 14 13:18:47 nice touch :) Jul 14 13:19:10 oops Jul 14 13:19:11 :) Jul 14 13:19:32 now to wedge a sleep 3 in to get around #551 :) Jul 14 13:19:39 tig|: :) Jul 14 13:19:43 broken for you as well? Jul 14 13:20:07 (please state that in trac with some info about your setup so we'll be able to find the source of the problem) Jul 14 13:20:15 :{ Jul 14 13:20:29 ah right I assumed I just needed to do it, but will test first Jul 14 13:20:42 I was getting random dbus borked on restart anyway Jul 14 13:20:52 I just generally rebooted it Jul 14 13:27:03 TAsn_: no I didn't fix it I had no time Jul 14 13:27:05 I'll do that now Jul 14 13:27:44 TAsn_: hmmm it works here without the sleep, but I was getting random dbus borkage before Jul 14 13:29:29 Ainulindale: cool, let me know, as I want to mod and test ophonekitd :) Jul 14 13:31:45 excuseme: does someone use saskia? Jul 14 13:47:31 tracfeed: Ticket #551 (Ophonekitd doesn't start at boot after latest upgrade) updated Jul 14 14:15:26 pbaxter: that sounds somewhat sexist ;D Jul 14 14:16:21 what DocScrutinizer? Jul 14 14:16:43 use saskia Jul 14 14:17:03 # Jul 14 14:17:36 (never let your son close to your keyboard ;) Jul 14 14:17:43 hehe Jul 14 14:17:53 already was about to ask ;) Jul 14 14:19:11 mrmoku`: do you remember about some chat with mickey about a hypothetical tool possibly named lsresource ? Jul 14 14:34:31 DocScrutinizer, hmm... no Jul 14 16:26:16 tracfeed: Ticket #551 (Ophonekitd doesn't start at boot after latest upgrade) updated Jul 14 16:27:59 can someone help me with navit? Jul 14 16:40:20 tracfeed: Ticket #554 (usb0 configuration) created Jul 14 16:47:58 dos1: you are phonelog? Jul 14 16:48:21 DocScrutinizer: i'm human :P Jul 14 16:50:15 anyway (due to me still not able to open ticket on trac.shr): steps to reproduce Jul 14 16:50:35 1)shr-u-20090703 Jul 14 16:51:05 2) inbound call, reject Jul 14 16:51:40 3)click on "1 missed call" -> phonelog opens Jul 14 16:52:46 4) call-back the number from phonelog. "Release" Jul 14 16:53:33 5) "1 missed call" popps up Jul 14 16:53:51 goto 3) Jul 14 16:54:37 14) close phonelog(s) XD Jul 14 16:55:23 dos1: i think i found a bug in your opimd-messages test-app: Messages from my girlfriend arrive under the name of an other contact Jul 14 16:55:25 dos1: is this of any relevance to you? Jul 14 16:56:56 s/still not able/still not allowed/ Jul 14 16:57:26 DocScrutinizer: and what happens? Jul 14 16:58:27 hmm, exactly what I described above. The procedure itself seems somewhat odd, as are the multiple phonelog screens *for sure* Jul 14 16:59:32 DocScrutinizer: few phonelogs windows? Jul 14 16:59:36 dos1: I dunno if multiple settings-power instances are a feature. But for phonelog I tend to consider multi-instatiation a bug Jul 14 17:00:15 DocScrutinizer: well, that's not phonelog issue. more notifier one :P Jul 14 17:00:27 it just makes system.os("phonelog &") AFAIK Jul 14 17:00:37 s/system.os/os.system/ Jul 14 17:00:38 dos1 meant: it just makes os.system("phonelog &") AFAIK Jul 14 17:00:45 hmm, yup. you might be right Jul 14 17:01:18 opimd-notifier can replace now "standard" notifier, as it supports both messages and missed calls ;) Jul 14 17:01:32 yes Jul 14 17:01:41 great Jul 14 17:02:02 i like that gui. after completing opimd i'll try to make it lfd-phonegui compliable Jul 14 17:02:16 and make it complete GUI, not only test app ;) Jul 14 17:02:24 now unify notifier with the main-app... :) Jul 14 17:02:45 DocScrutinizer: Jul 14 17:02:57 I didn't see what dos1 wrote Jul 14 17:03:01 though notifier has a bug Jul 14 17:03:10 it counts missed outgoing calls as missed Jul 14 17:03:17 (at least from what I noticed) Jul 14 17:03:18 TAsn_: huh? Jul 14 17:03:21 TAsn_: oh, you reminded me Jul 14 17:03:27 i have bugfix for that Jul 14 17:03:27 [19:59] 5) "1 missed call" popps up Jul 14 17:03:28 :D Jul 14 17:03:34 I also stumbled across that :) Jul 14 17:03:40 dos1: don't fix it Jul 14 17:03:46 rewrite it to use opimd Jul 14 17:03:47 :) Jul 14 17:03:49 as i have used notifier as base for opimd code ;) Jul 14 17:03:49 yes, this might be part of syndrome Jul 14 17:03:55 TAsn_: well, i have opimd-notifier ;) Jul 14 17:04:01 really? Jul 14 17:04:03 why don't we use itL Jul 14 17:04:04 it's in opimd-utils Jul 14 17:04:04 ? Jul 14 17:04:17 why don't we use it? Jul 14 17:04:20 TAsn_: cause it's test script Jul 14 17:04:30 does it work? Jul 14 17:04:32 which works as daily notifier as well Jul 14 17:04:33 :D Jul 14 17:04:38 exactly :) Jul 14 17:04:38 but it also handles messages Jul 14 17:04:46 dos1: just drop the messages part Jul 14 17:04:49 notifier also does messages Jul 14 17:04:53 (which btw sucks) Jul 14 17:05:13 TAsn_: well, it works in different way Jul 14 17:05:26 (different gui) Jul 14 17:05:29 and not only Jul 14 17:05:34 hm.. Jul 14 17:05:43 then just "fix" notifier (i.e switch to opimd) Jul 14 17:05:44 now opimd-notifier just replaces ophonekitd notifing and notifier Jul 14 17:05:55 in future i want to make it phonegui library Jul 14 17:05:57 but that's later Jul 14 17:05:59 actually with the missed calls signal you have in opimd Jul 14 17:06:14 it's easy to make notifier correct Jul 14 17:06:21 on signal count++ Jul 14 17:06:22 :) Jul 14 17:06:35 TAsn_: it's even easier Jul 14 17:06:43 dos1: hehe writing a notifer (and actually a phonelog) in phonegui is also in mine todo ;) Jul 14 17:06:44 TAsn_: there is NewMissedCalls signal Jul 14 17:06:45 my* Jul 14 17:06:58 dos1: which has a count? Jul 14 17:07:02 TAsn_: yep Jul 14 17:07:06 lol cool :) Jul 14 17:07:14 then write us a notifier!!! Jul 14 17:07:14 :) Jul 14 17:07:22 TAsn_: it's used in oeventsd, so you can write rules about for instance blinking led Jul 14 17:07:23 ;) Jul 14 17:07:59 nah ;) Jul 14 17:08:11 it works here, but there is bug with handling leds in oeventsd Jul 14 17:08:14 I also don't like the blinking led on incoming call Jul 14 17:08:14 :) Jul 14 17:08:29 anyhow Jul 14 17:08:33 give us a notifier! :) Jul 14 17:08:37 (opimd base of course) Jul 14 17:08:54 TAsn_: you put a ticket in for that? :) Jul 14 17:09:04 about notifier? no Jul 14 17:09:07 as it's not an shr app Jul 14 17:09:15 and I have no idea where to reach the dev Jul 14 17:09:16 when one rule is untriggered, it turns led off, even if second rule which uses it is still triggered Jul 14 17:09:19 dos1: led-bug???? elaborate! Jul 14 17:09:21 nor did I have time to confirm the bug :) Jul 14 17:09:36 DocScrutinizer: ^^^ Jul 14 17:09:55 dos1: oevents should add a ref count :) Jul 14 17:10:10 TAsn_: code looks like it's there Jul 14 17:10:14 but doesn't work Jul 14 17:10:23 hehe, ok ;) Jul 14 17:10:46 TAsn_: exactly (refcnt) Jul 14 17:11:13 dos1: filename? Jul 14 17:11:16 doesn't the request for the blinking led resource Jul 14 17:11:29 holds a refcount? Jul 14 17:11:45 (is there even such resource?) Jul 14 17:11:46 should Jul 14 17:11:55 TAsn_: there isn't Jul 14 17:11:55 hmm Jul 14 17:12:01 ;\ Jul 14 17:12:02 :-( Jul 14 17:12:10 * TAsn_ smells a bug Jul 14 17:12:20 resources should always work this way Jul 14 17:12:29 as they are *SHARED* resources :) Jul 14 17:12:33 TAsn_: that's not resource Jul 14 17:12:41 a led? Jul 14 17:12:44 yep Jul 14 17:12:57 then what is it ? Jul 14 17:13:00 for 03 we thought about a rather smart way to store procedures for LED-manager chip Jul 14 17:13:56 TAsn_: odeviced dbus call Jul 14 17:14:09 well, (resource) it's not easy to define what "share" means Jul 14 17:14:36 for a boolean/int Jul 14 17:16:23 it's rather same situation as we see for alsamixer Jul 14 17:17:10 we need sort of "scenario" managment for this class of resource Jul 14 17:18:15 or at least exclusive resource allocation Jul 14 17:19:02 which in the end is the most simple form of scenario-management Jul 14 17:56:37 TAsn_: deleting packages now works :) Jul 14 17:56:49 implementing installing is almost copy-paste Jul 14 17:56:54 :))) Jul 14 17:57:07 which means shr-installer now works? Jul 14 17:57:07 :) Jul 14 17:57:28 though i have to check and think about overwriting configuration files Jul 14 17:57:58 hm.. how to handle that? do you have bindings for that in packagekit? Jul 14 17:58:00 TAsn_: you can now use shr-installer instead of opkg update and opkg remove ;) Jul 14 17:58:12 dos1: I don't remove packages :) Jul 14 17:58:18 TAsn_: i don't know. that's why i said that ;) Jul 14 17:58:20 dos1: and of course upgrade, right? Jul 14 17:58:27 upgrades* Jul 14 17:58:35 TAsn_: not now Jul 14 17:58:48 TAsn_: there is bug in packagekit, it causes infinite loop :( Jul 14 17:58:59 dos1: for some reason I thought you said you already finished that :) Jul 14 17:59:05 dos1: infinite loop = bad :) Jul 14 17:59:09 (duh) Jul 14 17:59:15 TAsn_: i said that it's my priority Jul 14 17:59:25 TAsn_: but when implementing that, i discovered that bug Jul 14 17:59:47 i'll try to fix it, i've already packagekit repo cloned Jul 14 17:59:50 dos1: cool :) so there *was* a bug :) Jul 14 17:59:53 heyho Jul 14 18:00:08 anyhow, I think we should really address what the configuration files issue I talk about all the time. don't you agree? Jul 14 18:00:16 s/what/the/ Jul 14 18:00:18 TAsn_ meant: anyhow, I think we should really address the the configuration files issue I talk about all the time. don't you agree? Jul 14 18:00:19 TAsn_: which? Jul 14 18:00:23 dos1: I saw you started a elm-based packet manager, great! Jul 14 18:00:34 that they SHOULD NOT resolve in packages Jul 14 18:00:36 mickeyl: ping Jul 14 18:00:42 TAsn_: i think it should ask only if version in package has changed Jul 14 18:01:05 morphis: yep :) Jul 14 18:01:07 I mean, files that change should NOT be shipped with to their final destination with the package Jul 14 18:01:22 dos1: version? i.e 0.3.x to 0.4.x? Jul 14 18:01:34 that's also bad! Jul 14 18:01:41 TAsn_: no Jul 14 18:01:52 TAsn_: it's done correctly in dpkg Jul 14 18:02:08 i have config file in package with content "foo" Jul 14 18:02:10 dos1: how is it done there? Jul 14 18:02:21 i'm upgrading, and i have still "foo" in conf file Jul 14 18:02:21 oh Jul 14 18:02:22 ok Jul 14 18:02:23 got it Jul 14 18:02:23 so everything is ok Jul 14 18:02:25 then Jul 14 18:02:26 okie Jul 14 18:02:29 yeah yeah Jul 14 18:02:30 okie :) Jul 14 18:02:32 :) Jul 14 18:02:42 this is A LOT better Jul 14 18:02:45 but still not optimal Jul 14 18:03:09 i think it's optimal, as you can see when default configuration has been REALLY changed Jul 14 18:03:17 and you can then compare your config with default Jul 14 18:03:34 dos1: anyhow, your idea is better than the current one Jul 14 18:03:40 and requires little to no effort Jul 14 18:03:58 only (hopefuly) minor opkg patches Jul 14 18:04:00 TAsn_: could you try to implement it? ;) Jul 14 18:04:05 dos1: sure Jul 14 18:04:15 though only on thursday evening Jul 14 18:04:16 it would be really nice! Jul 14 18:04:24 as I want to study for my test :) Jul 14 18:04:33 hehe :) Jul 14 18:04:37 again, good luck ;) Jul 14 18:05:11 let's just hope I won't die from looking at the opkg mess :) Jul 14 18:05:21 I remember getting dizzy last time I reviewed the code ;) Jul 14 18:05:33 anyhow, will do. :) Jul 14 18:06:45 tracfeed: Ticket #484 (Don't put configuration files in the packages.) updated Jul 14 18:06:47 dos1: one last thing Jul 14 18:06:51 I need your opinion about Jul 14 18:07:06 let's say Jul 14 18:07:19 I have a conf file Jul 14 18:07:21 shipped as is Jul 14 18:07:25 from the package Jul 14 18:07:28 didn't edit it Jul 14 18:07:43 and then new version brings a new config Jul 14 18:08:06 should I just overwrite? (as the user didn't even tocuh the config) confirm? Jul 14 18:08:10 then don't ask Jul 14 18:08:17 that's what dpkg do Jul 14 18:08:23 cool. Jul 14 18:12:17 http://feeds.digg.com/~r/digg/container/technology/popular/~3/DMrMt3ipo7o/Rumor_YouTube_Will_Be_Next_To_Drop_IE6_Support <--- the world is becoming a better place Jul 14 18:12:17 :) Jul 14 18:17:01 nice :) Jul 14 18:41:41 TAsn_: dos1: ice you guys understand without words almost. I didn't get anything about Dos' idea how to handle .cfg. My aproach is: either apply *patches* to config-files, or (alternative if structure changed too much) create a copy of old .cfg (bla.cfg.SAVE), then replace with new one and print warning. OR if structure changed but app knows old cfg syntax, copy new .cfg to bla.cfg.NEW for user reference, and print notice Jul 14 18:43:00 DocScrutinizer: I know, that's what I thought about (the patching idea) though this requires more work on the packager's side Jul 14 18:43:15 as for dos1's idea, it's just a change in the default behavior Jul 14 18:43:25 -in Jul 14 18:43:46 DocScrutinizer: I won't be fixing anything, just changing the default behavior so it'll be a bit less annoying Jul 14 18:43:58 (i.e will only pop up when there's a real dispute) Jul 14 18:44:30 DocScrutinizer: ask user only if config has changed between version in already installed package and version in installed now package Jul 14 18:45:00 as dpkg does for ages Jul 14 18:46:18 dos1: nah, you need md5 checksum, to find user modified .cfg anyway Jul 14 18:46:25 DocScrutinizer: exactly Jul 14 18:46:38 you gotta keep the current md5sum Jul 14 18:47:16 * DocScrutinizer off for a beer now Jul 14 18:47:19 bbl Jul 14 18:47:23 ciao Jul 14 18:47:24 enjoy. Jul 14 18:57:34 SHR: 03seba.dos1 07shr-installer * rbd5c065e78c1 10/shr-installer: Implement removing packages. Jul 14 18:57:38 freesmartphone.org: 03Frederik.Sdun 07dbus-hlid * r8fcf31fd5088 10fso-monitord/ (6 files in 2 dirs): Use new Value transformation for Logger. Needs vala 0.7.4 Jul 14 18:59:45 another bug in packagekit (i think both are in opkg backend) - when removing multiple packages, only first one is really removed, and after that 'package-not-installed' is returned Jul 14 19:00:00 looks like i really have to look in opkg backend ;) Jul 14 19:03:58 dos1: sucks :) Jul 14 19:04:04 btw, until then Jul 14 19:04:07 just iterate Jul 14 19:04:19 although this is sucky, at least we'll have a "working product" Jul 14 19:04:30 it's all async Jul 14 19:04:50 but i'll try to do that Jul 14 19:05:29 TAsn_: i'm upgrading my broken e installation on PC, and then i'll run shr-installer on PC with dpkg backend Jul 14 19:05:33 s/dpkg/apt/ Jul 14 19:05:33 dos1 meant: TAsn_: i'm upgrading my broken e installation on PC, and then i'll run shr-installer on PC with apt backend Jul 14 19:05:35 ;) Jul 14 19:05:43 :) Jul 14 19:06:12 TAsn_: http://www.packagekit.org/pk-matrix.html Jul 14 19:07:31 dos1: opkg looks a bit "missing"? :) Jul 14 19:07:37 or may I say, grey? Jul 14 19:08:08 that's what's funny about SHR and actually many other moko distros and apps Jul 14 19:08:17 we spend most of our time Jul 14 19:08:26 choosing incomplete apps to depend on Jul 14 19:08:34 and just dev for them :) Jul 14 19:09:14 i.e, vala, packagekit, connman and many more :) Jul 14 19:09:22 TAsn_: but that's fun! Jul 14 19:09:27 hehe, it is Jul 14 19:09:29 I'm having a blash Jul 14 19:09:31 I'm just saying ;) Jul 14 19:09:35 blast( Jul 14 19:09:39 blast* bah ;) Jul 14 19:10:08 but most of important things are already there (non-grey) Jul 14 19:10:11 That's why we can't seem to finish as much as we may want to Jul 14 19:10:17 dos1: yeah, saw that. Jul 14 19:10:27 just the comparison vs others looked a bit funny :) Jul 14 19:10:36 TAsn_: well, opkg backend was created in 0.1.x branch Jul 14 19:10:46 TAsn_: after that were only commits to make it compilling :x Jul 14 19:10:47 and was discontinued? Jul 14 19:10:52 i c ;) Jul 14 19:11:07 TAsn_: cause opkg backend was developed by openmoko, when ASU was developer Jul 14 19:11:09 d Jul 14 19:11:37 yeah, figured. Jul 14 19:11:53 what gui did 2007.2 use for package management? Jul 14 19:12:13 TAsn_: i don't think 2007.2 had gui package manager Jul 14 19:12:31 there was some app, but i haven't managed it to work Jul 14 19:12:47 oh, ok, I thought I remembered something Jul 14 19:12:54 but I have no idea whether it worked or not Jul 14 19:13:06 btw, dos1 as for the notifier app, got a sample for me? Jul 14 19:13:16 (the fix for notifier to work with opimd) Jul 14 19:13:16 TAsn_: sample? Jul 14 19:13:22 you said you had something ready Jul 14 19:13:31 TAsn_: just listen to NewMissedCalls signal Jul 14 19:13:34 and nothing else :) Jul 14 19:13:41 I know what to do Jul 14 19:13:47 I remember you said you had something :) Jul 14 19:14:05 hmm... but then you have to change New to 0 in new calls ;x Jul 14 19:14:13 TAsn_: you can look at opimd-notifier Jul 14 19:15:21 yeah, I know Jul 14 19:15:32 I can esaily do it myself, though I thought you said you had something ready Jul 14 19:15:39 if you don't, nvm :) Jul 14 19:15:43 anyhow, I really gotta study Jul 14 19:15:44 ciao. Jul 14 19:32:31 mrmoku|away: Do you have any idea whose responsibility is to tweak default bluetoothd config? Jul 14 19:41:45 mickeyl: ping Jul 14 19:53:36 hmm. running shr latest. gpsprof says: first fix in 42.04 sec.. but tangogps says no gps found Jul 14 19:53:38 PaulFertser: obviously yours Jul 14 19:53:46 ;-) Jul 14 19:53:51 any ideas where to scratch tangogps? Jul 14 19:54:30 DocScrutinizer: i'm not even an SHR dev Jul 14 19:54:31 scratch? Jul 14 19:54:32 :D Jul 14 19:55:00 nevermind.. now it got it.. Jul 14 19:55:02 weird Jul 14 20:00:29 let's hope I'm not dead :) Jul 14 20:00:43 it seems like I'm alive ;) Jul 14 20:00:46 finally! Jul 14 20:01:33 DocScrutinizer (or was it PaulFertser? or both?), as you can see, I haven't solved (actually haven't tried) fixing this annoying issue (connection killed when connecting to freenode) Jul 14 20:01:56 TAsn: you haven't solved? Jul 14 20:02:01 haven't, no. Jul 14 20:02:10 TAsn: so what did you do instead? Jul 14 20:02:11 it still only sometimes work Jul 14 20:02:23 I try to connect every 10 hours Jul 14 20:02:27 hoping it won't kill my connection Jul 14 20:02:33 and when I succeed I try not to leave Jul 14 20:02:34 :) Jul 14 20:02:36 that's about it. ;) Jul 14 20:02:49 that's hardly a solution :) Jul 14 20:07:03 lol Jul 14 20:07:08 oops, wrong chan Jul 14 20:31:34 SHR: 03seba.dos1 07shr-installer * rfaca08526e6b 10/shr-installer: Implement installing :) Jul 14 20:32:24 ok, i'm off now Jul 14 20:32:28 good night :) Jul 14 20:32:30 dos1, gj Jul 14 20:32:32 night :) Jul 14 20:33:57 what did dos1 accomplish? Jul 14 20:35:50 F4t: he is working on a elementary based opkg/packagekit GUI Jul 14 20:36:27 oh, cool Jul 14 20:37:19 yep, but he said there are some bugs in the packagekit opkg backend, which needs to be fixed first. Jul 14 20:38:09 Slyon_, though Jul 14 20:38:10 opkg update Jul 14 20:38:12 whats scapy's url? Jul 14 20:38:15 okg remove Jul 14 20:38:21 and as it seems opkg install Jul 14 20:38:23 work Jul 14 20:38:33 (opkg remove is buggy when removing more than one package) Jul 14 20:38:37 F4t, don't you use ff? Jul 14 20:39:01 TAsn: right Jul 14 20:39:13 TAsn, i do, i just cleared cache and history... :-/ Jul 14 20:39:29 oh :) Jul 14 20:39:41 because I never remember scap's address as well, I just use the awesome bar Jul 14 20:39:55 http://scap.linuxtogo.org/ Jul 14 20:40:00 thanks :) Jul 14 20:40:18 uhhhh a screenie of arch linux on the moko Jul 14 20:41:25 yes Jul 14 20:41:29 saw it as well :) Jul 14 20:41:37 I remember someone here talking about porting arch Jul 14 20:42:14 <|Leto|> mhm opkg and buggy? :-D Jul 14 20:42:19 <|Leto|> no way :P Jul 14 20:42:42 not like the sky is blue Jul 14 20:42:45 :> Jul 14 20:45:42 whos the guy that has his moko connected to "Von Fritz IT"? Jul 14 20:47:06 F4t, my guess Heinervdm Jul 14 20:47:09 though I'm not sure Jul 14 20:47:21 :) Jul 14 20:57:04 TAsn: I don't know "Von Fritz IT" Jul 14 20:57:16 oh, so it's not you ;) Jul 14 20:57:26 I thought you also worked on shr-installer Jul 14 20:57:36 as the suspect was probably an shr-installer dev :) Jul 14 20:58:18 I made only a bb reciepe for it, i think dos1 is the only dev, isn't he? Jul 14 20:58:31 look in scap Jul 14 21:01:17 ah, "Von Fritz IT" sounds like a german company, but i don't know a company like that Jul 14 21:01:49 IT sounds italian though ;) Jul 14 21:02:16 yes but von isn't an italian word und fritz is a german name :) Jul 14 21:06:12 by the way, F4t it would be nice if mokonnect starts the wifi on it's own, if a profile with wifi is configured Jul 14 21:06:53 F4t, aye! you can just check to see how shr-settings does it. Jul 14 21:06:55 it's very easy. Jul 14 21:06:56 :) Jul 14 21:07:26 Request the wifi resource and hold it Jul 14 21:07:32 as long as needed Jul 14 21:14:36 Heinervdm, http://www.assembla.com/spaces/shrdev/tickets/9-Allow-powering-up-and-down-the-devices-in-question- Jul 14 21:15:12 By the way, connmand might have problems with that, since it currently needs to be killed and rerun after powering on wifi, for it to detect it... Jul 14 21:16:07 F4t, Jul 14 21:16:11 so please add: Jul 14 21:16:21 "until fixed: kill and rerun connmand" Jul 14 21:16:22 :) Jul 14 21:16:38 i think i might do it myself from the python... Jul 14 21:16:46 it annoys me that much Jul 14 21:16:47 F4t: ok, good to know that you've already planed it Jul 14 21:17:00 F4t, do what yourself? kill and rerun? Jul 14 21:17:01 you should... Jul 14 21:17:37 TAsn, ye Jul 14 21:17:49 anyway, im off for about 15 mins Jul 14 21:18:10 i'm off to bed, gn8 Jul 15 02:07:09 ~botsnack Jul 15 02:07:10 DocScrutinizer: aw, gee **** ENDING LOGGING AT Wed Jul 15 02:59:57 2009