**** BEGIN LOGGING AT Sun Apr 19 02:59:57 2009
Apr 19 03:00:00 <wurp2> although I set up my script before SHR had an option for it
Apr 19 03:00:30 <Blu3> four clicks + the long time for the gui to do things
Apr 19 03:01:55 <wurp2> Anyone using a bt kbd?
Apr 19 03:02:06 <wurp2> Mine won't connect, but I'm not sure if it might be a kbd issue
Apr 19 03:02:14 <wurp2> e.g. low batteries on the kbd
Apr 19 03:02:39 <Blu3> i need to get one
Apr 19 03:02:52 <rozzin> wupr2: I probably get something
Apr 19 03:02:54 <wurp2> I've been very happy with my ThinkOutside
Apr 19 03:03:07 <rozzin> lik 60 words per minute.
Apr 19 03:03:11 <wurp2> (assuming that my problems now are neo related, not kbd related ;-)
Apr 19 03:03:17 <wurp2> rozzin: nice!
Apr 19 03:03:21 <wurp2> Do you use it much?
Apr 19 03:03:29 <rozzin> Not recently.
Apr 19 03:03:50 <rozzin> I wanted to get a couple of them for work, but they went out of production right before I would have placed my order :\
Apr 19 03:04:03 <wurp2> :-(
Apr 19 03:04:10 <rozzin> And I mainly use my TouchStream at home.
Apr 19 03:04:26 <rozzin> I pull out the Twiddler when I'm painting and/or GIMPing.
Apr 19 03:04:34 <wurp2> Kinesis for me
Apr 19 03:04:47 <wurp2> Twiddler was supposed to be the first step in my mobile computing platform
Apr 19 03:04:56 <wurp2> which now would be easy, with the neo
Apr 19 03:04:59 <rozzin> Because being able to sketch with one hand and  keyboard/mouse with the other is, like... *wicked* fast.
Apr 19 03:05:28 <rozzin> After using the Twiddler for a while, I'll get sort-of frustrated when
Apr 19 03:05:36 <wurp2> But I also have a more realistic view now of how often mobile computing would actually benefit me (at least, in contexts where I would want a keyboard)
Apr 19 03:05:36 <rozzin> I go back to a regular keyboard.
Apr 19 03:06:06 <rozzin> Because I can't emit things like "The" or "ing" with single keystrokes on a regular keyboard :)
Apr 19 03:06:35 <rozzin> Well, just think about 24/7 omnipresent
Apr 19 03:06:41 <rozzin> IRC :)
Apr 19 03:07:05 <wurp2> The only time I don't have access to IRC when I might want it... I'm driving
Apr 19 03:07:13 <wurp2> So I don't think IRCing would be a good idea
Apr 19 03:07:14 <rozzin> Well, there you go.
Apr 19 03:07:25 <rozzin> I'll watch the obituaries for you ;)
Apr 19 03:07:32 <wurp2> thanks
Apr 19 03:07:37 * Blu3 can drive, text, and chew gum at the same time
Apr 19 03:07:38 <wurp2> It's nice to know someone is watching out for me
Apr 19 03:07:40 <rozzin> Er, I guess that's a ":(".
Apr 19 03:07:44 <Blu3> unlike the common person on the road
Apr 19 03:08:10 <wurp2> I resist the urge to fiddle with the neo while on the road
Apr 19 03:08:12 <wurp2> almost always
Apr 19 03:08:56 <wurp2> btw, the ThinkOutside also has a little stand you can put the neo on
Apr 19 03:09:04 <rozzin> Someone mentioned the possibility of doing accelerometer-based `virtual hard buttons', somewhere...
Apr 19 03:09:19 <wurp2> No accel for me :-(  -- 1973
Apr 19 03:09:37 <wurp2> Oh!
Apr 19 03:09:46 <wurp2> Anyone know why my .bashrc doesn't execute?
Apr 19 03:09:53 <wurp2> when I term in
Apr 19 03:10:49 <mwester> because the shell isnt' bash?
Apr 19 03:10:54 <rozzin> might be interesting to get something, based on that, sort-of like the the keyboard that Jecec de Assumpcao was working on for his Merlin computers;
Apr 19 03:11:09 <rozzin> Um..., where's that link...
Apr 19 03:11:09 <wurp2> mwester: Well, I changed it to /bin/bash in /etc/passwd
Apr 19 03:11:17 <wurp2> and "set -o vi" works
Apr 19 03:11:19 <mwester> Oh, so you installed bash then.
Apr 19 03:11:22 <wurp2> yeah
Apr 19 03:11:32 <wurp2> And I have a mode 755 .bashrc
Apr 19 03:11:39 <wurp2> which doesn't run unless I run it manually
Apr 19 03:12:59 <wurp2> Also, anyone know why ntpclient was remove from the repository?
Apr 19 03:16:03 <wurp2> Whoa, gllin is in the repository now?
Apr 19 03:16:08 <wurp2> I thought that was legally a no-no
Apr 19 03:16:12 <rozzin> Ah! Here we go:
Apr 19 03:16:15 <rozzin> http://www.merlintec.com/lsi/merlin4.7/features.html
Apr 19 03:24:46 <DocScrutinizer> mwester: I'm not sure about that
Apr 19 03:28:15 <DocScrutinizer> wurp2: for ((i=1; i<2; i++)) do; echo $i; done   works in your "bash"?
Apr 19 03:29:20 <DocScrutinizer> s/ do;/: do/
Apr 19 03:29:38 <DocScrutinizer> s/ do;/; do/
Apr 19 03:30:04 <DocScrutinizer> s/ do\;/\; do/
Apr 19 03:30:56 <DocScrutinizer> mwester: what's wrong with bzzbot?
Apr 19 03:31:51 <DocScrutinizer> s/what/What/
Apr 19 03:31:51 <bzzbot> DocScrutinizer meant: mwester: What's wrong with bzzbot?
Apr 19 03:32:01 <DocScrutinizer> s/what/What;/
Apr 19 03:32:08 <DocScrutinizer> s/what/What/
Apr 19 03:32:08 <bzzbot> DocScrutinizer meant: s/What/What;/
Apr 19 03:32:46 <DocScrutinizer> s/what/What/
Apr 19 03:32:47 <bzzbot> DocScrutinizer meant: s/What/What;/
Apr 19 03:32:56 <DocScrutinizer> :-/
Apr 19 03:34:18 <wurp2> DocScrutinizer: Yes, it works in my "bash"
Apr 19 03:34:34 <wurp2> set -o vi doesn't work in sh
Apr 19 03:36:06 <DocScrutinizer> hmm it at least doesn't throw error on my busybox shit
Apr 19 03:36:26 <wurp2> Really?
Apr 19 03:36:27 <DocScrutinizer> for (( does
Apr 19 03:36:38 <wurp2> Can you then hit esc and k and see your prior command?
Apr 19 03:36:42 <wurp2> But I did try your ((
Apr 19 03:36:45 <wurp2> and it echoed 1
Apr 19 03:36:51 <wurp2> once I removed the ; after do
Apr 19 03:37:10 <DocScrutinizer> ;)
Apr 19 03:38:02 <BillK> has anyone been able to get shr-contacts to build
Apr 19 03:38:14 <BillK> on a fresh shr-testing
Apr 19 03:38:26 <BillK> built clean from scratch
Apr 19 03:38:34 <BillK> breaks at the install stage
Apr 19 03:38:41 <wurp2> BillK: One would assume it builds as a part of the full build... I know Julian (Ainulindale) did it yesterday or the day before
Apr 19 03:38:51 <wurp2> I don't know that he did it from scratch, but I think he did
Apr 19 03:39:01 <BillK> Yes, but Julien used is already built image to do it
Apr 19 03:39:07 <BillK> I'm starting clean so 
Apr 19 03:39:12 <BillK> something is missing
Apr 19 03:39:18 <wurp2> He did?  He needs his hand slapped then.
Apr 19 03:39:31 <wurp2> Releases should always be built clean
Apr 19 03:39:44 <BillK> takes too long so most devs just build on top of what they have
Apr 19 03:39:48 <BillK> understandable
Apr 19 03:40:07 <BillK> but I am always running into issues like this that
Apr 19 03:40:13 <BillK> "builds for me"
Apr 19 03:40:18 <wurp2> Well, releases should really happen on a build server... and I thought it did
Apr 19 03:40:22 <wurp2> On the bearstech server
Apr 19 03:40:31 <wurp2> For just the reasons you're running into
Apr 19 03:41:00 <BillK> At least the glibc, vala-native and other glitches were fixed
Apr 19 03:42:50 <wurp2> Well, I can't really bitch about Julian
Apr 19 03:43:13 <wurp2> Since I wrote the first web page for SHR, and he actually made it happen ;-)
Apr 19 03:44:05 <BillK> Be interesting if anyone else has been able to build current shr-testing
Apr 19 03:44:07 <wurp2> While I did next to nothing
Apr 19 03:44:13 <BillK> and runs into the same thing ...
Apr 19 03:44:27 <wurp2> yeah
Apr 19 03:56:14 * mwester has built shr-testing several times in the past 3 days.
Apr 19 03:56:20 <mwester> from scratch
Apr 19 03:57:35 <BillK> ok, I'll rm rm -rf for the 4th time since the change was made to the new shr-testing and start again ...
Apr 19 03:57:51 <mwester> Why would it be different?
Apr 19 03:58:07 <mwester> Why not find out what is wrong with your env that is causing the breakage?
Apr 19 03:58:42 <BillK> thats what I want to know - what could be wrong - its a clean checkout, its built on and off in the (distant!) past
Apr 19 04:00:47 <BillK> mwester: when you say you have built successfully
Apr 19 04:00:59 <BillK> was that rm -rf everything except downloads
Apr 19 04:01:08 <BillK> and recheckout from there?
Apr 19 04:02:12 <mwester> I do all sorts of ways, including that.
Apr 19 04:02:22 <BillK> k
Apr 19 04:02:49 <mwester> Why don't you post (pastebin) the logs from where its failing, so we can see what the messages are.
Apr 19 04:07:45 <BillK> ok, just did some logging out/in and resetting up as the console I an using had been up for days
Apr 19 04:08:23 <playya_> bitbake logs everything
Apr 19 04:09:27 <BillK> yes, I had the logs - gets to the install stage and make complains that
Apr 19 04:09:37 <BillK> there is no install method or some such
Apr 19 04:11:06 <playya_> paste the last one. maybe we can tell you what happend/whats wrong
Apr 19 04:18:56 <playya_> good night
Apr 19 04:25:36 <BillK> mwester: http://pastebin.com/d6ba63512
Apr 19 04:25:40 <BillK> make update
Apr 19 04:25:43 <BillK> make image
Apr 19 04:25:48 <BillK> cat install.log
Apr 19 04:26:29 <BillK> no difference between make image or bitbake clean shr-contacts etc
Apr 19 04:40:12 <mwester> Add the following line to your local.conf file and see if anything changes:
Apr 19 04:40:16 <mwester> SRCREV_pn-shr-contacts = "${AUTOREV}"
Apr 19 04:53:38 <BillK> k
Apr 19 05:08:09 <Gorbusch> hi
Apr 19 05:12:03 <BillK> mwester: part succes, built through shr-contacts and died at shr-messages, same error
Apr 19 05:12:35 <BillK> Is the SRCREV_pn just grabbing the latest version?
Apr 19 05:13:18 <Gorbusch> i have tried to build my shr image again up from scratch, it fails with shr-contacts telling me
Apr 19 05:13:18 <Gorbusch> make DESTDIR=/...shr-contacts.../image install
Apr 19 05:13:18 <Gorbusch> make: *** No rule to make target 'install'. Stop.
Apr 19 05:13:18 <Gorbusch> How can i resolve such an error?
Apr 19 05:14:01 <mwester> Yes.  Ainulindale made some large change in that last commit.  Not sure why or what; the previous one builds for me, but apparently your system doesn't like it.  Try just adding a similar AUTOREV line for each of the ones that gives you trouble...
Apr 19 05:14:23 <BillK> Gorbusch: see mwesters comments now, aboy same thing
Apr 19 05:14:56 <mwester> Or you can just build shr-unstable; I've just rebuilt that here, and it builds ok right now as well.
Apr 19 05:14:58 <BillK> ok, its building now - seems another is also having the problem
Apr 19 05:17:29 <mwester> Let me guess - shr-dialer
Apr 19 05:20:03 <Gorbusch> it currently the first error i get is:
Apr 19 05:20:04 <Gorbusch> ERROR: Multiple .bb files are due to be built which each provide xext (/home/frank/stuff1/shr-testing/openembedded/recipes/xorg-lib/libxext_1.0.3.bb /home/frank/stuff1/shr-testing/openembedded/recipes/xorg-lib/libxext-native_1.0.4.bb).
Apr 19 05:20:04 <Gorbusch>  This usually means one provides something the other doesn't and should.
Apr 19 05:20:04 <Gorbusch> ERROR: Multiple .bb files are due to be built which each provide virtual/xserver (/home/frank/stuff1/shr-testing/openembedded/recipes/xorg-xserver/xserver-kdrive-glamo_1.3.0.0+git.bb /home/frank/stuff1/shr-testing/openembedded/recipes/xorg-xserver/xserver-kdrive_1.3.0.0.bb).
Apr 19 05:20:30 <Gorbusch> have run a update of shr just few minutes before
Apr 19 05:20:47 <mwester> It's still building
Apr 19 05:21:41 <BillK> Gorbusch: that error just build through I think - no consequence that I can see
Apr 19 05:21:46 <Gorbusch> yes
Apr 19 05:21:54 <Gorbusch> the error which fails is again the shr-contacts
Apr 19 05:22:21 <BillK> Gorbusch: Add the following line to conf/local.conf
Apr 19 05:22:43 <BillK> Gorbusch: SRCREV_pn-shr-contacts = "${AUTOREV}"
Apr 19 05:23:02 <BillK> Gorbusch: and one for shr-messages, my next failure
Apr 19 05:24:27 <Gorbusch> BillK: done, what is the purpose of those lines?
Apr 19 05:25:37 <BillK>  Gorbusch: They were suggested by mwester as a wokaround - they seem to
Apr 19 05:25:52 <BillK> pull the latest version from git for that package
Apr 19 05:26:36 <BillK> mwester: correct, shr-dialler just died the same way.
Apr 19 05:32:10 <CIA-75> SHR: 03mwester 07shr-overlay * r510bd31b6715 10/openembedded/conf/distro/include/shr-autorev.inc: shr-autorev.inc: update shr PREFERRED_VERSIONS to make testing build reliably.
Apr 19 05:33:12 <CIA-75> SHR: 03mwester 07shr-overlay * r510bd31b6715 10/openembedded/conf/distro/include/shr-autorev.inc: shr-autorev.inc: update shr PREFERRED_VERSIONS to make testing build reliably.
Apr 19 05:33:12 <CIA-75> SHR: 03mwester 07shr-overlay * r9e3de87c7bba 10/openembedded/conf/distro/include/shr-autorev.inc: Merge commit 'origin/master' into testing
Apr 19 05:34:17 <mwester> Ok, well those updates just done pull testing forward to the most recent version (same as unstable)... can't make anything worse, so why not?
Apr 19 05:34:57 <BillK> k, BB still spooling up to build shr-dialler - I'll make update
Apr 19 05:35:19 <BillK> and remove those lines from local.conf now you have committed the fix
Apr 19 05:46:25 <Gorbusch> nothing else failed after the line for dialer was inserted
Apr 19 05:47:25 <BillK> Gorbusch: mine died - spelt dialer wrong :(
Apr 19 06:19:18 <Blu3> ok, my suspicions were right.  shr sms message handler is losing track of messages.  it claims they are deleted but rather they are still on the sim
Apr 19 06:28:06 <DocScrutinizer> Blu3: cool finding. can you fix it?
Apr 19 06:28:35 <Blu3> eventually.  i am really pressed on time for the next few weeks tho
Apr 19 06:29:03 <DocScrutinizer> so maybe better to open a ticket on SHR
Apr 19 06:29:13 <Blu3> just figured it was pretty odd that i only had a few contacts and one SMS message, and framework was reporting the sim card was full
Apr 19 06:29:30 <Blu3> put it in an old phone and spent 10 minutes deleting old messages
Apr 19 06:29:41 <DocScrutinizer> yup
Apr 19 07:47:36 <neobaka> hi
Apr 19 08:22:04 <neobaka> question: which command initiates a suspend from a console window? (if any)
Apr 19 08:24:40 <lindi-> apm -s
Apr 19 08:25:39 <neobaka> tnx, i'll try
Apr 19 08:26:02 <PaulFertser> neobaka: or echo mem > /sys/power/state
Apr 19 08:26:23 <PaulFertser> neobaka: but! If gsm modem is turned on and not prepared properly, it will wake up the system pretty soon.
Apr 19 08:26:39 <neobaka> mem? what does "mem" mean for /power/state?
Apr 19 08:27:01 <gurugentoo> ram/memory...
Apr 19 08:27:40 <neobaka> the moden... aha that's the reason why it woke up oO" now i know
Apr 19 08:29:24 <neobaka> 2nd question... if i flash Qi and then go back to uboot, is there a possibility to backup/restore the menu settings? or are they hardcoded?
Apr 19 08:30:21 <PaulFertser> neobaka: NAND u-boot stores environment on a separate NAND partition.
Apr 19 08:30:50 <neobaka> does this partition get deleted when flashing Qi?
Apr 19 08:31:02 <lindi-> neobaka: depends on how you flash Qi :)
Apr 19 08:31:18 <lindi-> neobaka: you are not supposed to flash Qi over uboot_env but if you make a mistake you can do that too
Apr 19 08:31:47 <neobaka> okay, means if i follow the wiki instructions, the partition is kept?
Apr 19 08:32:43 <PaulFertser> lindi-: :)
Apr 19 08:34:42 <neobaka> lindi, and if i kill NOR too, you will have to guide me through the degug-board flashing process ;)
Apr 19 08:48:41 <PaulFertser> neobaka: why are you going to kill NOR? And how?
Apr 19 08:49:48 <neobaka> i won't. but you could by flashing it from NAND couldn't you?
Apr 19 08:51:22 <PaulFertser> neobaka: Without connecting a dboard or other means of hardware hacking you won't be able to write to NOR.
Apr 19 08:52:34 <neobaka> hehe, so i could, 'cause i have the board *fg*
Apr 19 08:53:26 <neobaka> buit i thought you could access the NOR by software. good that you can't. my mistake
Apr 19 08:54:18 <PaulFertser> neobaka: you can access the NOR by software. But you can't enable write to it without external circuit.
Apr 19 08:55:04 <neobaka> aah, the wsod... now to the second suspend ^^
Apr 19 08:55:44 <PaulFertser> neobaka: have you tried the kernel with Nicolas patch reverted?
Apr 19 08:56:09 <neobaka> no. but the second suspend restores the screen oO"
Apr 19 08:56:15 <neobaka> wow
Apr 19 08:58:38 <neobaka> lets try a second time and freeeze the device a bit before second restore ;)
Apr 19 09:02:05 <neobaka> tzk... i cannot unplug usb during suspend -.- so no freezing :(
Apr 19 09:12:20 <DocScrutinizer> err, not unplug?
Apr 19 09:12:53 <neobaka> yes, but my intention was to put the FR out of the window
Apr 19 09:13:17 <neobaka> (throw it through the window?)
Apr 19 09:13:20 <DocScrutinizer> why you can't unplug?
Apr 19 09:14:05 <neobaka> makes an event and wakes the device again. sencond issue: cable too short
Apr 19 09:14:35 <DocScrutinizer> so maybe unplug *prior* to suspend?
Apr 19 09:14:55 <neobaka> then i cant "apm -s" by console
Apr 19 09:15:01 <lindi-> xterm
Apr 19 09:15:11 <lindi-> wlan
Apr 19 09:15:14 <lindi-> timer
Apr 19 09:15:33 <DocScrutinizer> timer sounds quite reasonable
Apr 19 09:16:03 <lindi-> just add countdown clock and blinking leds :)
Apr 19 09:16:05 <DocScrutinizer> nohup sleep 60 && apm -s
Apr 19 09:16:18 <neobaka> xterm? how's that going to work? no wlan here, timer... umm... difficult
Apr 19 09:16:30 <neobaka> is the timer stopped when suspended?
Apr 19 09:16:36 <lindi-> neobaka: rtc timer is not
Apr 19 09:17:10 <neobaka> it should, because i want it to start counting when i wake the device to a WSOD
Apr 19 09:17:17 <DocScrutinizer> huh? what for U need a timer *after* apm -s fired??
Apr 19 09:17:40 <neobaka> WSOD, second apm -s necessary
Apr 19 09:17:56 <DocScrutinizer> login via ssh?
Apr 19 09:18:14 <neobaka> cable? ;)
Apr 19 09:18:18 <DocScrutinizer> or simply enable suspend after 30 from setup
Apr 19 09:18:35 <neobaka> that doesnt work for some reason
Apr 19 09:18:48 <neobaka> (not during wsod, that is)
Apr 19 09:19:04 <DocScrutinizer> I really really don't get it how ppl make problems out of nothing, or just don't come to the point
Apr 19 09:19:30 <neobaka> point is: i am supposed to test the behaviour during wsod
Apr 19 09:19:45 <DocScrutinizer> duh! so wsod is affecting usb?!?!???
Apr 19 09:19:49 <neobaka> and i want the second resube be at a low temperature
Apr 19 09:20:26 <neobaka> resume at low temperature cant be done with usb-cable plugged in, cause the cable is too short
Apr 19 09:20:41 <neobaka> thats all. nothing fancy
Apr 19 09:20:51 * DocScrutinizer always thought there was some sort of automatic suspend
Apr 19 09:21:14 * neobaka thinks wsod is affecting that
Apr 19 09:21:34 <DocScrutinizer> nope why should it?
Apr 19 09:22:17 <neobaka> because the GUI isnt restored properly perhaps? i don't know. obviousely i wait ages and the device won't suspend any more
Apr 19 09:23:08 <DocScrutinizer> so you got no wsod but a severe different problem
Apr 19 09:23:56 <neobaka> there is a white screen after resume, so wsod it is. other problem might be unrelated
Apr 19 09:24:40 <DocScrutinizer> wsod is a hw issue between glamo and LCM. no way to affect USB or suspend or any other userland or kernel functions
Apr 19 09:24:42 <PaulFertser> DocScrutinizer: Yes, there's some problem with frameworkd sometimes where it doesn't want to send device to sleep.
Apr 19 09:25:02 <PaulFertser> DocScrutinizer: pure userland issue.
Apr 19 09:25:12 <DocScrutinizer> nevertheless thats absolutely not related to wsod
Apr 19 09:25:17 <neobaka> ...and i therefore send the device there by apm -s
Apr 19 09:25:17 <PaulFertser> Sure
Apr 19 09:26:45 <DocScrutinizer> so another case of "search under latern"?
Apr 19 09:27:00 <PaulFertser> Hehe, true
Apr 19 09:27:04 <neobaka> what?
Apr 19 09:27:51 <lindi-> neobaka: you can schedule the phone to resume by calling it or by RTC timer
Apr 19 09:28:37 <neobaka> lindi: we were thinking of sending it to sleep, not waking it. waking is easy
Apr 19 09:28:53 <PaulFertser> Sending is even easier.
Apr 19 09:29:00 <lindi-> neobaka: i don't see the problem
Apr 19 09:29:25 <DocScrutinizer> lindi-: nobody does
Apr 19 09:29:39 <DocScrutinizer> except neobaka 
Apr 19 09:29:42 <neobaka> omg... please stop the discussion! let's settle to: i don't test low temperature and get on with flashing Qi
Apr 19 09:29:49 <PaulFertser> lindi-: like mwester told me yesterday, you're thinking from a Debian user POV, he's thinking from a phone user POV.
Apr 19 09:31:28 <PaulFertser> SHR devs should provide a nice elementary GUI app for scheduling arbitrary commands.
Apr 19 09:31:54 <DocScrutinizer> yup. cool idea
Apr 19 09:32:19 <PaulFertser> Actually it was sarcastic.
Apr 19 09:33:55 <DocScrutinizer> 3iner involving 'at' and OMdialog (mwester's port of Kdialog)
Apr 19 09:34:34 <DocScrutinizer> ah wait, we got sth already. it's called shell
Apr 19 09:34:41 <neobaka> maybe they should do a button: you press it and the phone "just works"(TM)
Apr 19 09:35:43 <DocScrutinizer> it's already there.  you didn't notice yet ;-)
Apr 19 09:36:27 <BillK> I just flashed a newly built shr-testing
Apr 19 09:36:34 <BillK> cant talk to the gsm at all
Apr 19 09:36:39 <neobaka> depending of how you define "just works" you are definitely correct: i call it the power button ;)
Apr 19 09:36:46 <BillK> get "rxerr: port=0 ch=0x00, rxs=0x0000000c" then nothing
Apr 19 09:36:53 <BillK> thought that was fixed?
Apr 19 09:37:12 <DocScrutinizer> neobaka: that's the one actually
Apr 19 09:37:44 <neobaka> ^^
Apr 19 09:40:41 <DocScrutinizer> BillK: 
Apr 19 09:40:45 <DocScrutinizer> root@om-gta02 / $ mickeyterm -c
Apr 19 09:40:46 <DocScrutinizer> <----------- Mickey's Term V2.9.3 @ /dev/pts/4 ----------->
Apr 19 09:40:48 <DocScrutinizer> AT-Command Interpreter ready
Apr 19 09:40:49 <DocScrutinizer> AT+CMEE=2;+CRC=1
Apr 19 09:40:51 <DocScrutinizer> OK
Apr 19 09:40:52 <DocScrutinizer> at
Apr 19 09:40:54 <DocScrutinizer> OK
Apr 19 09:40:55 <DocScrutinizer> Good Bye.
Apr 19 09:41:03 <BillK> k
Apr 19 09:41:14 <DocScrutinizer> anyway then...
Apr 19 09:41:26 <DocScrutinizer> Good Bye.
Apr 19 09:41:28 <DocScrutinizer> Exception in thread Thread-1 (most likely raised during interpreter shutdown):
Apr 19 09:41:29 <DocScrutinizer> Traceback (most recent call last):
Apr 19 09:41:31 <DocScrutinizer>   File "/usr/lib/python2.6/threading.py", line 522, in __bootstrap_inner
Apr 19 09:41:32 <DocScrutinizer>   File "/usr/lib/python2.6/threading.py", line 477, in run
Apr 19 09:41:34 <DocScrutinizer>   File "/usr/bin/mickeyterm", line 553, in reader
Apr 19 09:41:35 <BillK> DocScrutinizer: actually that wont work, mux wont connect
Apr 19 09:41:35 <DocScrutinizer> <type 'exceptions.OSError'>: [Errno 9] Bad file descriptor
Apr 19 09:41:37 <DocScrutinizer> root@om-gta02 / $  
Apr 19 09:41:48 <BillK> error occurs after mux starts and then ... nothing
Apr 19 09:42:15 <DocScrutinizer> hmm, mickeyterm is using mux (by default)
Apr 19 09:42:22 <DocScrutinizer> afaik
Apr 19 09:42:27 <PaulFertser> BillK: can you try to not start at all and instead do the socat trick lindi- described at https://docs.openmoko.org/trac/ticket/2257 ?
Apr 19 09:42:33 <BillK> didnt think it could do otherwise
Apr 19 09:42:50 <BillK> tried socat on unstable a couple of days ago same problem
Apr 19 09:42:59 <BillK> tried minicom now, same problem
Apr 19 09:43:27 <DocScrutinizer> what's with mickeyterm?
Apr 19 09:43:40 <PaulFertser> BillK: have you followed lindi-'s instructions closely? Like start socat exactly like that, power-cycle the modem properly etc?
Apr 19 09:43:49 <BillK> crashing at exit - been doing it for some time
Apr 19 09:44:17 <DocScrutinizer> err, what's crashing?
Apr 19 09:44:25 <BillK> on unstable, see same symptoms now and I dont think 2.6.29 has changed in between
Apr 19 09:44:46 <BillK> mickyterm - cant exit cleanly like it used to - different problem
Apr 19 09:45:11 <DocScrutinizer> anyway it obviously can talk to modem
Apr 19 09:45:22 <DocScrutinizer> and it uses muxer
Apr 19 09:45:32 <DocScrutinizer> and it starts/stops modem
Apr 19 09:45:33 <BillK> not for me :(
Apr 19 09:45:34 <PaulFertser> DocScrutinizer: not to BillK's. He has a long-standing strange problem of communicating with the modem. 
Apr 19 09:45:53 <DocScrutinizer> ahh, ok then. dunno
Apr 19 09:46:06 <BillK> got it working fine with 2.6.28, was happy to do the same with 2.6.29 but
Apr 19 09:46:22 <BillK> cant get a spark out of it after that rxerr message
Apr 19 09:46:46 <DocScrutinizer> hmm, can't duplicate here
Apr 19 09:46:47 <PaulFertser> BillK: could you please try a kernel with mwester's nspy?
Apr 19 09:47:19 <BillK> ok, but will be next weekend - Ive been fiddling with this all afternoon
Apr 19 09:47:20 <DocScrutinizer> so in the end this seems to suggest you hw is broken
Apr 19 09:47:32 <BillK> and ive run out of time so have to flash back
Apr 19 09:47:37 <BillK> to old testing
Apr 19 09:47:59 <BillK> quite possibly hw is broken, but my own thoughts are that
Apr 19 09:48:23 <BillK> init of gsm chipset uart and kernel modules are not aligned
Apr 19 09:48:35 <BillK> and in some caes like mine its serious
Apr 19 09:48:47 <BillK> I suspect there are many others the same,
Apr 19 09:49:07 <BillK> but just leave the FR's on the shelf as "they have never worked"
Apr 19 09:49:31 <BillK> you see occaisional mail messages - most dont have the skills or time to chase
Apr 19 09:49:32 <DocScrutinizer> so how would your case differ from what I got with a fresh clean install of SHR here?
Apr 19 09:49:34 <BillK> it.
Apr 19 09:50:04 <BillK> That I dont know!
Apr 19 09:50:26 <BillK> I do know it worked fine with 2007.2, never with anything asu based
Apr 19 09:50:57 <DocScrutinizer> quite strange
Apr 19 09:50:58 <BillK> but with PaulFertser's help I was able to get shr working by init'ing the uart settings external to
Apr 19 09:51:12 <dos1> hmm
Apr 19 09:51:15 <BillK> the mux and remove that code from the mux itself
Apr 19 09:51:19 <DocScrutinizer> still it sounds like broken hw, as there seems to be no diference in sw
Apr 19 09:51:23 <dos1> now when Andy left, is there someone working on Qi?
Apr 19 09:52:00 <BillK> ah well, I'll see what nspy shows next week
Apr 19 09:52:14 <lindi-> any idea if I'll have trouble with airport security with my freerunner? ;)
Apr 19 09:52:33 <DocScrutinizer> fine. as long as your special "patches" don't make it into main branch
Apr 19 09:52:58 <DocScrutinizer> or lure people like me into thinking there's a general problem
Apr 19 09:54:21 <neobaka> lindi-: i don't know. perhaps as long as you don't tell them it could do strong encryprion you should be fine?
Apr 19 09:55:49 <budfive> lindi-: ugly cell-phones aren't illegal :)
Apr 19 09:55:50 <DocScrutinizer> lindi-: I passed customs with 5 FR some of which had nasty wires hanging out. If I were customs THAT was exactly what I thought a bomb looked like. No problem though ;D
Apr 19 09:55:59 <lindi-> neobaka: this is from finland to germany so no encryption trouble
Apr 19 09:56:39 <neobaka> lindi-: show them openmoocow ant say it's a cildrens toy *gg*
Apr 19 09:56:40 <DocScrutinizer> lindi-: duh, Munich??? that might be a different case ;-)
Apr 19 09:56:48 <Blu3> yay.  ophonekitd crashes on incoming sms/mms with out of memory errors
Apr 19 09:56:52 <lindi-> DocScrutinizer: München yes
Apr 19 09:57:21 <lindi-> ah, it's Munich in english, didn't know it had an english name :)
Apr 19 09:57:35 <DocScrutinizer> lindi-: usually there are no customs any more, just security check. 
Apr 19 09:58:01 <lindi-> yep
Apr 19 09:58:11 <lindi-> maybe i'll just keep the battery removed during the flight just to be sure
Apr 19 09:58:19 <DocScrutinizer> every german town has since at least 60y now ;-)
Apr 19 09:58:32 <DocScrutinizer> brunswick, nuremberg
Apr 19 09:59:08 <DocScrutinizer> some are identical to the german name though ;D
Apr 19 09:59:14 <DocScrutinizer> Berlin e.g.
Apr 19 09:59:51 <DocScrutinizer> lindi-: (batery) a very good idea
Apr 19 10:01:24 <DocScrutinizer> though danger of operating phones/other transmitters in airplane are largely overrated
Apr 19 10:02:07 <lindi-> DocScrutinizer: i thought it was mostly because of the trouble it causes to gsm networks when they see a phone that high :)
Apr 19 10:02:13 <DocScrutinizer> actually some airlines start to offer GSM via femtocell on board
Apr 19 10:02:21 <neobaka> they should be more concerned with the fat video-servers that do video on demand for business class
Apr 19 10:03:07 <DocScrutinizer> lindi-: lol. Actually they don't see it. usually not even on ground as airplane is a nearly perfect faraday cage
Apr 19 10:03:12 <lindi-> so, i'm asking again, is there something special I should see at Munich? I thought i'd visit the CCC (chaos computer club) if that is possible
Apr 19 10:03:21 <lindi-> DocScrutinizer: really?
Apr 19 10:03:36 <lindi-> DocScrutinizer: but haven't people made calls from airplanes?
Apr 19 10:03:44 <neobaka> dallmayr and get some coffee and cake
Apr 19 10:03:51 <DocScrutinizer> might or might not work. depends
Apr 19 10:04:34 <DocScrutinizer> lindi-: I don't think CCC is something you could "visit"
Apr 19 10:04:45 <DocScrutinizer> at least in munich
Apr 19 10:05:17 <lindi-> probably not at least before talking about it on #ccc
Apr 19 10:05:40 <DocScrutinizer> probably they meet once a week or month in some pub. for sure there is no office or the like that is open 9-5
Apr 19 10:06:02 <lindi-> once a week is ok for me :)
Apr 19 10:07:12 <DocScrutinizer> U know CCC.hh and CCC.berlin are rather big. Munich isn't that big
Apr 19 10:07:21 <Weiss> lindi-: go to the Deutsches Museum and see the high voltage demonstration :)
Apr 19 10:07:36 <DocScrutinizer> yep that's a really god idea :-)
Apr 19 10:07:42 <DocScrutinizer> good even
Apr 19 10:08:05 <DocScrutinizer> take your time for that though. will need a full day at least
Apr 19 10:08:18 <Weiss> yeah, deutsches museum will eat your time for breakfast
Apr 19 10:08:27 <DocScrutinizer> lol
Apr 19 10:08:55 <neobaka> ...you could go eat a roasted pigs leg at Haxlbaur
Apr 19 10:09:18 <DocScrutinizer> hm sounds like a nice plan as well
Apr 19 10:09:23 <DocScrutinizer> yummy
Apr 19 10:09:42 * lindi- adds POIs to tangogps...
Apr 19 10:09:50 <neobaka> it's "haxnbauer" actually
Apr 19 10:10:57 <DocScrutinizer> honestly best thing you can visit when traveling to Munich is Nuremberg ;-D
Apr 19 10:11:53 <neobaka> tip: don't order a whole haxn, you'll pay per kilo and wont#t be able to taste anything else. order a serving. then you get kraut with it.
Apr 19 10:12:21 <Weiss> neobaka: hehe.. i made that mistake :(
Apr 19 10:12:36 <neobaka> and? how large was it? *gg*
Apr 19 10:12:45 <DocScrutinizer> hehehe
Apr 19 10:13:03 <Weiss> more than i could possibly contemplate eating
Apr 19 10:13:09 <neobaka> lol ^^
Apr 19 10:13:45 <neobaka> best thing are the japanese: they are so shocked that they start photographing the thing so their relatives believe them ^^
Apr 19 10:14:05 <DocScrutinizer> lol
Apr 19 10:14:30 <DocScrutinizer> until it's cold I guess
Apr 19 10:14:45 <Weiss> actually i was at Andechs when i did my ordering "error"
Apr 19 10:14:59 <DocScrutinizer> andechs is ok :)
Apr 19 10:15:04 <Wonka> DocScrutinizer, lindi-: http://muc.ccc.de/treffen.html.en
Apr 19 10:16:27 <DocScrutinizer> lindi-: hmm, you're out of luck with CCC
Apr 19 10:22:02 <CIA-75> freesmartphone.org: 03mickey 07framework * r290a325a82cc 10/framework/subsystems/odeviced/audio.py: odevice: audio: refactor audio player to support multiple player engines (covering disjunct formats)
Apr 19 10:24:09 <Ainulindale> mickeyl: SO, THIS RECIPE REVIEW?
Apr 19 10:24:13 <Ainulindale> (woops, caps)
Apr 19 10:24:34 <mickeyl> yo, lets go over the recipes
Apr 19 10:24:41 <mickeyl> bottom to top
Apr 19 10:24:50 <mickeyl> what and how do you use SHR_PV?
Apr 19 10:24:55 <mickeyl> +for
Apr 19 10:25:53 <mickeyl> ah, inspecting the class now
Apr 19 10:25:55 <DocScrutinizer> moin mickeyl :)
Apr 19 10:25:58 <mickeyl> morning DocScrutinizer 
Apr 19 10:25:58 <Ainulindale> Well that's a crappy thing
Apr 19 10:26:05 <Ainulindale> That was originally done to handle local repositories
Apr 19 10:26:05 <mickeyl> agreed :)
Apr 19 10:26:18 <mickeyl> i'd rather see you using the standard PV/PR system than inventing something on top
Apr 19 10:26:45 <Ainulindale> Yeah but someone, can't recall who whined a lot about wanting to be able to use local repos
Apr 19 10:26:46 <dos1> mickeyl, Ainulindale: it isn't used anymore (SHR_PV), am i right?
Apr 19 10:26:50 <DocScrutinizer> Ainulindale: duck!
Apr 19 10:26:54 <Ainulindale> Yes it is used
Apr 19 10:26:58 <dos1> where?
Apr 19 10:26:59 <mickeyl> dos1: it's in almost every recipe
Apr 19 10:27:01 <Ainulindale> Everywhere
Apr 19 10:27:04 <dos1> oh
Apr 19 10:27:07 <dos1> ;D
Apr 19 10:27:09 <Ainulindale> mickeyl: every shr recipe
Apr 19 10:27:17 <Ainulindale> but it's easily swappable for PV
Apr 19 10:27:27 <mickeyl> ya, would be good if you could get rid of that
Apr 19 10:27:37 <onen> Zorkman: hi
Apr 19 10:27:58 <mickeyl> shr-settings does not fully honor the style guide
Apr 19 10:28:09 <Ainulindale> Tell that to dos1 :-)
Apr 19 10:28:11 <mickeyl> SRC_URI and S should be on top
Apr 19 10:28:17 <mickeyl> RDEPENDS close to the packages
Apr 19 10:28:22 <mickeyl> well, i tell it here
Apr 19 10:28:24 <mickeyl> since you wanted the review
Apr 19 10:28:41 <Ainulindale> Yes yes but that's a way to hilight him ;-)
Apr 19 10:29:11 <dos1> Ainulindale: it was me who writed bb recipe for shr-settings? :D
Apr 19 10:29:24 <Ainulindale> I think so
Apr 19 10:29:35 <mickeyl> as description i'd encourage you to go away from calling your apps "The Openmoko foo"
Apr 19 10:29:40 <mickeyl> i'd suggest "The SHR foo"
Apr 19 10:29:46 <Ainulindale> mickeyl: Did that as much as I could
Apr 19 10:29:50 <dos1> yep, it was me :D
Apr 19 10:29:50 <Ainulindale> There are some leftovers though
Apr 19 10:30:29 <dos1> but i really don't know anything about writing bb recipes
Apr 19 10:30:31 <dos1> :x
Apr 19 10:30:39 <dos1> so someone should correct it
Apr 19 10:30:42 <mickeyl> GPL2+ is not a valid LICENSE
Apr 19 10:30:54 <mickeyl> should read GPLv2
Apr 19 10:31:09 <mickeyl> or pester OE to include GPLv3 and then you can set both
Apr 19 10:31:44 <mickeyl> libframeworkd-phonegui_git.bb might use autotools_stage rather than a custom do_stage
Apr 19 10:32:05 <mickeyl> same for libframeworkd-phonegui-efl_git.bb
Apr 19 10:32:20 <mickeyl> SECTION might be wrong
Apr 19 10:32:25 <mickeyl> it's not an app or is it?
Apr 19 10:32:53 <Ainulindale> mickeyl: hmmm I thought it was necessary for staging
Apr 19 10:33:05 <Ainulindale> To stage the lib in OE
Apr 19 10:33:15 <mickeyl> check autotools_stage.bbclass
Apr 19 10:33:26 <mickeyl> it calls autotools_stage_all
Apr 19 10:33:33 <mickeyl> which stages both headers and libraries
Apr 19 10:33:36 <Ainulindale> (and for app, lfp-efl is between app and lib)
Apr 19 10:33:37 <mickeyl> (and if you want, also pkgconfig)
Apr 19 10:33:43 <Ainulindale> ok then I'll check that
Apr 19 10:33:45 <Ainulindale> Good to know
Apr 19 10:34:15 <mickeyl> e-wm-sysactions-shr_git.bb might have a problem with RREPLACES
Apr 19 10:34:27 <Ainulindale> Tell me more :-)
Apr 19 10:34:40 <mickeyl> that way you can no longer install the stock sysactions
Apr 19 10:34:47 <mickeyl> i'd recommend removing the RREPLACES
Apr 19 10:35:17 <mickeyl> ok, that all in [shr-overlay.git] / openembedded / recipes / shr 
Apr 19 10:35:34 <Ainulindale> Well that's all the truly necessary stuff
Apr 19 10:39:27 <bumbl> hmm either the lcm driver is utterly broken or my lcm is broken
Apr 19 10:39:40 <bumbl> as it does some really strange things on random occasions
Apr 19 10:43:08 <DocScrutinizer> bumbl: sounds scary
Apr 19 10:43:17 <bumbl> yeah it is
Apr 19 10:43:38 <DocScrutinizer> bumbl: you disassembled your device ?
Apr 19 10:44:52 <bumbl> from a purple screen of death to disorted scren of death to the reproducable screen of death you get when xrandr -o 1 and then suspend
Apr 19 10:45:30 <DocScrutinizer> bumbl: anyway gently touching the FPC (the thing covered by steel fabric sticky tape) 
Apr 19 10:45:51 <DocScrutinizer> might reveal if it's a simple contact issue
Apr 19 10:46:07 <bumbl> DocScrutinizer: at the beginning i removed the frontcover to place the display protector ordered at schutzfolien24.de (which most poeple @ #neo1973-germany use)
Apr 19 10:46:28 <bumbl> but there weren't any problems at that time until a week ago
Apr 19 10:46:30 <bumbl> so i
Apr 19 10:46:33 <DocScrutinizer> hmm, might have triggered sth
Apr 19 10:46:38 <bumbl> 'd rather suspect the kernel
Apr 19 10:47:37 <CIA-75> SHR: 03ainulindale 07shr-overlay * r889e5ebd827d 10/openembedded/ (9 files in 2 dirs): shr.bbclass: Removed SHR_PV handling. Updated files accordingly.
Apr 19 10:48:12 <DocScrutinizer> bumbl: if it's nothing but the kernel, I should see same issue, no?
Apr 19 10:48:32 <bumbl> i didn't ever have a wsod
Apr 19 10:48:48 <bumbl> but since that was fixed i had various other issues
Apr 19 10:49:06 <bumbl> e.g. nsod after resuming with qi,...
Apr 19 10:49:15 <bumbl> which all got fixed seperatly
Apr 19 10:50:36 * bumbl hopes the planned rewrite of the lcm driver will fix some problems
Apr 19 10:51:06 <CIA-75> SHR: 03ainulindale 07shr-overlay * re417961edc97 10/openembedded/recipes/shr/frameworkd-config-shr_git.bb: frameworkd-config-shr: Eventually fixed the directory issue. I withdraw my comments on dos1, even though he's mean
Apr 19 10:51:07 <CIA-75> SHR: 03ainulindale 07shr-overlay * r85ee0269525f 10/openembedded/recipes/shr/frameworkd-config-shr_git.bb: frameworkd-config-shr: Fix -f by -d. This is dos1 fault for not warning
Apr 19 10:51:07 <CIA-75> SHR: 03ainulindale 07shr-overlay * rc2fc888091ae 10/openembedded/recipes/shr/frameworkd-config-shr_git.bb: frameworkd-config-shr: Fixed southern redneck shouting SRCREV about racoon and stuff.
Apr 19 10:51:08 <CIA-75> SHR: 03ainulindale 07shr-overlay * re8ca0ee98343 10/openembedded/ (9 files in 2 dirs): shr.bbclass: Removed SHR_PV handling. Updated files accordingly.
Apr 19 10:51:26 <DocScrutinizer> I wouldn't hold breath
Apr 19 10:51:28 <CIA-75> SHR: 03ainulindale 07shr-overlay * r51ff5d8680f2 10/openembedded/recipes/shr/frameworkd-config-shr_git.bb: frameworkd-config-shr: Fixed southern redneck shouting SRCREV about racoon and stuff.
Apr 19 10:51:29 <CIA-75> SHR: 03ainulindale 07shr-overlay * r22fb8b31f0ce 10/openembedded/recipes/shr/frameworkd-config-shr_git.bb: frameworkd-config-shr: Fix -f by -d. This is dos1 fault for not warning
Apr 19 10:51:29 <CIA-75> SHR: 03ainulindale 07shr-overlay * r7b3dd4cb2b51 10/openembedded/recipes/shr/frameworkd-config-shr_git.bb: frameworkd-config-shr: Fixed southern redneck shouting SRCREV about racoon and stuff.
Apr 19 10:51:30 <CIA-75> SHR: 03mwester 07shr-overlay * r86d2d4b84771 10/ (7 files in 4 dirs): Merge branch 'master' of git@shr.bearstech.com:shr-overlay.git into testing
Apr 19 10:51:39 <CIA-75> SHR: 03ainulindale 07shr-overlay * rb098cbc4f670 10/openembedded/recipes/shr/frameworkd-config-shr_git.bb: frameworkd-config-shr: Eventually fixed the directory issue. I withdraw my comments on dos1, even though he's mean
Apr 19 10:51:39 <CIA-75> SHR: 03ainulindale 07shr-overlay * r889e5ebd827d 10/openembedded/ (9 files in 2 dirs): shr.bbclass: Removed SHR_PV handling. Updated files accordingly.
Apr 19 10:51:42 <CIA-75> SHR: 03ainulindale 07shr-overlay * r85ee0269525f 10/openembedded/recipes/shr/frameworkd-config-shr_git.bb: frameworkd-config-shr: Fix -f by -d. This is dos1 fault for not warning
Apr 19 10:51:47 <CIA-75> SHR: 03ainulindale 07shr-overlay * re417961edc97 10/openembedded/recipes/shr/frameworkd-config-shr_git.bb: frameworkd-config-shr: Eventually fixed the directory issue. I withdraw my comments on dos1, even though he's mean
Apr 19 10:51:47 <dos1> WTF?
Apr 19 10:51:51 <CIA-75> SHR: 03ainulindale 07shr-overlay * re8ca0ee98343 10/openembedded/ (9 files in 2 dirs): shr.bbclass: Removed SHR_PV handling. Updated files accordingly.
Apr 19 10:51:54 <Ainulindale> (merging)
Apr 19 10:51:56 <CIA-75> SHR: 03mwester 07shr-overlay * r9e3de87c7bba 10/openembedded/conf/distro/include/shr-autorev.inc: Merge commit 'origin/master' into testing
Apr 19 10:52:01 <CIA-75> SHR: 03ainulindale 07shr-overlay * rc2fc888091ae 10/openembedded/recipes/shr/frameworkd-config-shr_git.bb: frameworkd-config-shr: Fixed southern redneck shouting SRCREV about racoon and stuff.
Apr 19 10:52:41 <DocScrutinizer> cia-storm
Apr 19 10:52:44 <DocScrutinizer> hehe
Apr 19 10:53:37 <bumbl> yes
Apr 19 10:54:14 <bumbl> dos1: seems you did something wrong ;)
Apr 19 10:54:50 <CIA-75> SHR: 03ainulindale 07shr-overlay * r0a05c818c683 10/openembedded/recipes/shr/ (e-wm-sysactions-shr_git.bb shr-config_git.bb): e-wm-sysactions-shr: Removed RREPLACE.
Apr 19 10:54:50 <CIA-75> SHR: 03ainulindale 07shr-overlay * r0a05c818c683 10/openembedded/recipes/shr/ (e-wm-sysactions-shr_git.bb shr-config_git.bb): e-wm-sysactions-shr: Removed RREPLACE.
Apr 19 10:55:02 <Ainulindale> (double commit)
Apr 19 10:55:38 <Ainulindale> Ok I'll eat and check the rest later
Apr 19 10:55:54 <dos1> bumbl: no, that was Dave's fault of course
Apr 19 10:56:13 <bumbl> dks
Apr 19 10:56:15 <bumbl> dl
Apr 19 10:56:32 * bumbl should stop hitting the keyboard
Apr 19 10:56:39 <bumbl> dos1: of course he is
Apr 19 10:59:38 * DocScrutinizer is missing Dave
Apr 19 11:01:56 <neobaka> sorry to go back to this issue: do you realize that the SHR will not suspend again if you don't touch anything after waking up?
Apr 19 11:02:33 <dos1> neobaka: it's frameworkd problem
Apr 19 11:02:40 <dos1> neobaka: after waking up by button?
Apr 19 11:02:51 <neobaka> so it is known? yes after waking up by button
Apr 19 11:03:15 <CIA-75> freesmartphone.org: 03mickey 07framework * r65ac2fde54f8 10/framework/ (6 files in 6 dirs): refactor killall into framework.patterns.utilities module
Apr 19 11:03:31 <dos1> mickeyl: is frameworkd setting busy state after waking from suspend?
Apr 19 11:03:55 <mickeyl> iirc yes
Apr 19 11:04:06 <dos1> neobaka: no, but it's FSO issue to suspend and detect idlleness
Apr 19 11:05:08 <neobaka> mh, okay. that one fooled me a while ago when i tested aroung my wsod (i dont touch there because i can't see..)
Apr 19 11:05:11 <dos1> btw. who knows, when mrmoku will be back?
Apr 19 11:05:52 <DocScrutinizer> ~seen mrmoku
Apr 19 11:05:52 <bzzbot> mrmoku <n=mrmoku@ppp-93-104-106-217.dynamic.mnet-online.de> was last seen on IRC in channel #openmoko-cdevel, 5d 14h 51m 49s ago, saying: 'see you all soon'.
Apr 19 11:06:15 <DocScrutinizer> hmm, didn't he say "2 weeks"?
Apr 19 11:06:44 <dos1> DocScrutinizer: i don't remember what he said, so that's what i was asking about ;)
Apr 19 11:07:45 <DocScrutinizer> I seem to remember 2weeks, but I thought it's been 2weeks ago and maybe I'm completely wrong
Apr 19 11:08:24 <dos1> DocScrutinizer: yep, 5 days ago he was online from some bar with free wifi access
Apr 19 11:08:32 <dos1> so he should be there... now ;x
Apr 19 11:08:48 <DocScrutinizer> ahh, so maybe I'm actually right
Apr 19 11:08:55 <DocScrutinizer> yup
Apr 19 11:09:18 <dos1> 5 days ago he said that he has working opimd-feeded contact list
Apr 19 11:09:49 <dos1> (i suppose he doesn't have message list, as i fixed messages few days ago...)
Apr 19 11:10:15 <neobaka> where do I find the current version of Wi for GTA02v5 please?
Apr 19 11:10:20 <neobaka> Qi
Apr 19 11:10:33 <DocScrutinizer> oh you did? someone complained abot that this night
Apr 19 11:10:43 <dos1> neobaka: http://people.openmoko.org/andy/
Apr 19 11:10:48 <dos1> DocScrutinizer: who, why?
Apr 19 11:11:35 <DocScrutinizer> who: forgot. why:sms isn't deleted despide framework thinks it succeeded (iigtr)
Apr 19 11:11:58 <neobaka> umm... is there a reason why the s3c6410 isn't called ".udfu" or ".bin"?
Apr 19 11:12:14 <DocScrutinizer> huh?
Apr 19 11:12:32 <dos1> DocScrutinizer: wtf? what opimd has to do with deleting messages?
Apr 19 11:12:47 <DocScrutinizer> dunno
Apr 19 11:12:58 <Ainulindale> neobaka: mwester commited patches for preventing WSOD on latest for SHR
Apr 19 11:13:01 <dos1> DocScrutinizer: AFAIK opimd Sources aren't initialized on startup, you have to do it manually
Apr 19 11:13:06 <dos1> and deleting messages works for me
Apr 19 11:13:36 <bumbl> dos1: afaik opimd stores messages too
Apr 19 11:14:33 <dos1> bumbl: but not by default. you have to InitializeSources or something like that at each boot
Apr 19 11:14:49 <bumbl> hmm 'kay
Apr 19 11:15:04 <bumbl> to sum it up
Apr 19 11:15:05 <neobaka> Ainulindale: could you rephrase "on latest for SHR", i don't understand
Apr 19 11:15:13 <bumbl> opimd at the moment is a big mess
Apr 19 11:15:18 <Ainulindale> latest kernel
Apr 19 11:15:22 <dos1> and if it's initialized - there is no app which uses opimd
Apr 19 11:15:31 <dos1> so even if opimd stores message
Apr 19 11:15:48 <dos1> shr-contacts or zhone or paroli doesn't know about that
Apr 19 11:16:15 <dos1> btw. opimd doesn't store messages now, it's only using SIM as backend
Apr 19 11:16:43 <bumbl> hmm
Apr 19 11:16:52 <DocScrutinizer> dos1: 
Apr 19 11:16:56 <DocScrutinizer> [04:58] <Blu3> and my contact list is almost full too
Apr 19 11:17:11 <DocScrutinizer> in #openmoko
Apr 19 11:17:57 <dos1> DocScrutinizer: i don't get the point ;x
Apr 19 11:18:13 <neobaka> Ainulindale: where do i get that? i'm currently testing the 2.6.10-oe10...r3.3 from testing (which is also the latest in unstable)
Apr 19 11:19:27 <DocScrutinizer> dos1: it's been Blu3 who stated he found an error in deleting SMS. do you have a backlog of #openmoko?
Apr 19 11:19:35 <tilman> dos1: is there an om bug for http://trac.shr-project.org/trac/ticket/309 ? i can't find it
Apr 19 11:20:01 <tilman> mwester's ar6000 oops fix just gets me back the no-lease problem :(
Apr 19 11:20:34 <DocScrutinizer> DocScrutinizer: using SIM backend is the problem as it fills up rapidly
Apr 19 11:20:40 <DocScrutinizer> grr
Apr 19 11:21:04 <DocScrutinizer> dos1: ^
Apr 19 11:21:49 <DocScrutinizer> anyway me away in a few minutes
Apr 19 11:27:08 <dos1> i don't understand
Apr 19 11:27:27 <dos1> nothing uses opimd
Apr 19 11:27:34 <dos1> so even when there are bugs in opimd
Apr 19 11:27:53 <dos1> noone care about it now (except mrmoku :P)
Apr 19 11:28:58 <dos1> and i fixed only tracebacks in python, and one api inconsintance
Apr 19 11:30:35 <mickeyl> shoragan: ping
Apr 19 11:34:27 <bumbl> nice said Doc
Apr 19 11:34:46 <budfive> mickeyl: secretsauce.net:5050/frameworkd.conf
Apr 19 11:35:21 <mickeyl> that's wrong
Apr 19 11:35:28 <mickeyl> ti_calypso_muxer_type
Apr 19 11:35:30 <mickeyl> instead of
Apr 19 11:35:32 <mickeyl> ti_calypso_muxer
Apr 19 11:36:18 <budfive> mickeyl: aha. did that setting get renamed recently?
Apr 19 11:36:34 <budfive> mickeyl: that config file is mostly vanilla from a not-so-recent shr install
Apr 19 11:36:53 <mickeyl> not really, perhaps i have a wrong value in the sample config
Apr 19 11:36:57 <mickeyl> key, that is
Apr 19 11:37:12 <budfive> could be
Apr 19 11:37:23 <bumbl> dos1: well then start using it ;)
Apr 19 11:38:06 <budfive> mickeyl: in either case, i'm running the test now. Is there anything the old muxer does better than the new one? Any reason for me to go back?
Apr 19 11:38:22 <dos1> bumbl: mrmoku has contacts. i have few lines in python to test messages ;D
Apr 19 11:38:34 <dos1> and i will post usefull opimd code snippets on wiki
Apr 19 11:38:50 <dos1> maybe someone will work on it then
Apr 19 11:38:53 <bumbl> ok
Apr 19 11:39:08 <dos1> for me it took 3 days to understand opimd ;d
Apr 19 11:39:09 <dos1> ;D
Apr 19 11:39:43 <dos1> if only there were some docs, it would be much easier
Apr 19 11:39:55 <dos1> or examples
Apr 19 11:40:04 <mickeyl> budfive: the new muxer should be better in all areas, however it has not been tested that much, so it could have bugs.
Apr 19 11:40:05 <dos1> but there are no docs and no examples
Apr 19 11:40:23 <mickeyl> budfive: i'm using it with zhone for a while without any problems though
Apr 19 11:40:50 <mickeyl> make sure you have 0.3.3 btw., older versions didn't honor FC
Apr 19 11:40:57 <budfive> mickeyl: ok. seeing some areas of non-functionality right now, but I don't know what to blame yet. 
Apr 19 11:40:59 <mickeyl> [as well as libgsm0710mux, which does the acutal work]
Apr 19 11:41:21 <budfive> mickeyl: i built it all yesterday, or maybe the day before 0.3.3 for abyss for sure
Apr 19 11:42:18 <mickeyl> make sure you don't have the older muxer in the background, else they will fight for resources
Apr 19 11:42:37 <budfive> mickeyl: ok. old muxer not running, only new. 
Apr 19 11:42:37 <mickeyl> to debug, you can manually start fso-abyss in one terminal
Apr 19 11:42:43 <mickeyl> then start ogsmd in another one
Apr 19 11:42:54 <mickeyl> it will pick up the already running instance
Apr 19 11:43:51 <budfive> mickeyl: i started gprs, it came up. I downloaded some of the site, and the download stopped. Calypso was not dead. This has happened previously, and would get fixed with a gprs deactivation and reactivation
Apr 19 11:44:20 <budfive> mickeyl: however, this time, org.freesmartphone.GSM.PDP.GetContextStatus always says "active" even after repeated calls to org.freesmartphone.GSM.PDP.DeactivateContext
Apr 19 11:44:31 <mickeyl> sounds like ppp is still running
Apr 19 11:44:32 <budfive> mickeyl: it is definitely not active. ppp0 is not up
Apr 19 11:44:50 <budfive> mickeyl: yes. you're right. pppd is indeed running
Apr 19 11:44:58 <mickeyl> right, ppp is hanging for some reason then
Apr 19 11:45:06 <mickeyl> there's no "shutting down" in between of active and release
Apr 19 11:45:10 <mickeyl> might add that
Apr 19 11:45:18 <mickeyl> i actually hate having to use ppp
Apr 19 11:45:22 <mickeyl> it's so over the top
Apr 19 11:45:27 <budfive> mickeyl: ok. i'll kill pppd i suppose
Apr 19 11:45:36 <mickeyl> we could handle it all on our own if we had a lightweight ppp library that does the handshake
Apr 19 11:46:20 <budfive> mickeyl: hmmm. pppd is no longer running, but is still says active
Apr 19 11:46:27 <mickeyl> that's sad
Apr 19 11:46:31 <budfive> mickeyl: even after deactivate()
Apr 19 11:46:33 <budfive> :(
Apr 19 11:47:03 <mickeyl> sometimes there's a full hang in FUTEX_WAIT
Apr 19 11:47:08 <mickeyl> something with child/parent process relationsship
Apr 19 11:47:15 <budfive> in what? the muxer? framework?
Apr 19 11:47:17 <mickeyl> didn't find the actual problem
Apr 19 11:47:25 <budfive> i can strace something if you like
Apr 19 11:47:27 <mickeyl> i guess somewhere in the glibc/kernel
Apr 19 11:47:32 <budfive> oh
Apr 19 11:47:35 <mickeyl> strace will only show it's hanging in FUTEX_WAIT
Apr 19 11:47:44 <mickeyl> been there done that ;)
Apr 19 11:47:52 <budfive> oof.
Apr 19 11:48:08 <budfive> well, i haven't seen this with the old muxer, so it's triggered by the new code probably
Apr 19 11:48:09 <mickeyl> (another reason why i hate subprocesses...)
Apr 19 11:48:20 <mickeyl> no, i've seen this with the old one as well
Apr 19 11:48:23 <budfive> ok
Apr 19 11:48:29 <mickeyl> the new one is faster though
Apr 19 11:48:36 <mickeyl> that could increase likelyness of hangs
Apr 19 11:48:43 <budfive> right. ok
Apr 19 11:48:44 <mickeyl> if it's a kernel/libc race condition
Apr 19 11:48:53 <DocScrutinizer> dos1: now I found it: [2009-04-19 08:19:19] <Blu3> ok, my suspicions were right.  shr sms message handler is losing track of messages.  it claims they are deleted but rather they are still on the sim
Apr 19 11:49:03 <DocScrutinizer> this channel
Apr 19 11:49:05 <budfive> mickeyl: this is my first attempt at trying to do anything with abyss. do you want me to try something, or should i cycle the framework and try again?
Apr 19 11:49:30 <mickeyl> try from a fresh boot
Apr 19 11:49:44 <dos1> DocScrutinizer: it looks like libframeworkd-phonegui-efl problem
Apr 19 11:50:01 <DocScrutinizer> k, no idea here ;)
Apr 19 11:52:17 <mickeyl> I'm also suspecting glib's spawn_async to have races :/
Apr 19 11:53:28 <DocScrutinizer> mickeyl: I got a strange error msg from mickeyterm on SHR. Interested?
Apr 19 11:53:46 <mickeyl> sure
Apr 19 11:54:09 <DocScrutinizer> at
Apr 19 11:54:11 <DocScrutinizer> OK
Apr 19 11:54:12 <DocScrutinizer> Good Bye.
Apr 19 11:54:14 <DocScrutinizer> Exception in thread Thread-1 (most likely raised during interpreter shutdown):
Apr 19 11:54:15 <DocScrutinizer> Traceback (most recent call last):
Apr 19 11:54:17 <DocScrutinizer>   File "/usr/lib/python2.6/threading.py", line 522, in __bootstrap_inner
Apr 19 11:54:18 <DocScrutinizer>   File "/usr/lib/python2.6/threading.py", line 477, in run
Apr 19 11:54:20 <DocScrutinizer>   File "/usr/bin/mickeyterm", line 553, in reader
Apr 19 11:54:21 <DocScrutinizer> <type 'exceptions.OSError'>: [Errno 9] Bad file descriptor
Apr 19 11:54:23 <DocScrutinizer> root@om-gta02 / $
Apr 19 11:54:57 <mickeyl> ah, that's normal
Apr 19 11:55:04 <DocScrutinizer> k ;D
Apr 19 11:55:05 <mickeyl> it doesn't gracefully shut down
Apr 19 11:55:21 <DocScrutinizer> that's fine for me
Apr 19 11:55:21 <mickeyl> i'll fix this with the reimplementation in vala which i have started yesterday
Apr 19 11:55:40 <DocScrutinizer> 8-)
Apr 19 11:56:00 <mickeyl> so we don't have to carry a python interpreter around when we just want a terminal ;)
Apr 19 12:00:06 <bumbl> DocScrutinizer: btw. how can i check whether my display has contact issues
Apr 19 12:00:33 <DocScrutinizer> as I mentioned: touch FPC
Apr 19 12:00:47 <bumbl> fpc=
Apr 19 12:00:49 <bumbl> ?
Apr 19 12:00:55 * bumbl googles
Apr 19 12:01:08 <DocScrutinizer> bumbl: anyway gently touching the FPC (the thing covered by steel fabric sticky tape) 
Apr 19 12:01:37 <DocScrutinizer> might reveal if it's a simple contact issue
Apr 19 12:01:57 <DocScrutinizer> bumbl: </quote>
Apr 19 12:02:12 <DocScrutinizer> flat plastic cable
Apr 19 12:02:44 <DocScrutinizer> or connector
Apr 19 12:03:13 <bumbl> DocScrutinizer: i have to open the case again for that? + as i don't have the display issues always (just once a day) it might not show anything else
Apr 19 12:03:31 <budfive> mickeyl: very similar failure this time. the connection stalled out, deactivate() didn't kill pppd
Apr 19 12:03:38 <DocScrutinizer> yup, remove front
Apr 19 12:04:05 <budfive> mickeyl: pppd didn't respond to SIGTERM, and had to be SIGKILLED
Apr 19 12:04:19 <mickeyl> yeah, sounds like one of these races in glib, glibc, kernel, etc.
Apr 19 12:04:26 <mickeyl> didn't see this for a while here
Apr 19 12:04:29 <mickeyl> which os are you on?
Apr 19 12:04:33 <budfive> mickeyl: after that, deactivate() produced a release status
Apr 19 12:04:53 <budfive> bug a subsequent activate() produces "/org/freesmartphone/GSM/Device: ActivateContext failed: org.freedesktop.DBus.Error.Failed"
Apr 19 12:05:05 <mickeyl> timeout?
Apr 19 12:05:22 <DocScrutinizer> sound like a case for gdb
Apr 19 12:05:24 <budfive> mickeyl: i'm using shr. not-so-recent install, but packages are mostly up-to-date
Apr 19 12:05:37 <budfive> fine. what do i gdb?
Apr 19 12:05:54 <budfive> i've never looked at any of this code
Apr 19 12:06:17 <mickeyl> moko11, i hope?
Apr 19 12:06:23 <budfive> moko12 even
Apr 19 12:06:29 <DocScrutinizer> I'd start with pppd id it doesn't answer to sigterm
Apr 19 12:06:35 <budfive> moko11 plus some of dieter's test code
Apr 19 12:06:42 <budfive> moko11 effectively
Apr 19 12:06:52 <mickeyl> ya, it'd be interesting to attach gdb to ppp and see where it's actually hanging
Apr 19 12:07:19 <budfive> k. rebooting. sigh
Apr 19 12:07:33 <DocScrutinizer> budfive: honestly there is no moko12. I'd downgrade to 11 anyway
Apr 19 12:08:37 <bumbl> DocScrutinizer: is dieter still at openmoko and working on the gsm fw
Apr 19 12:08:50 <DocScrutinizer> yup, kinda
Apr 19 12:09:15 <DocScrutinizer> he never was at OM in this sense. but he still continues
Apr 19 12:10:04 <bumbl> ok
Apr 19 12:10:17 <DocScrutinizer> actually ATM he's more "at OM" than me ;)
Apr 19 12:10:46 <bumbl> hehe
Apr 19 12:10:53 <bumbl> yep i know
Apr 19 12:12:51 <DocScrutinizer> and I really  hope he can fix or falsify the memleak bug eventually
Apr 19 12:14:54 <mickeyl> well it seems we can work around it, at last
Apr 19 12:15:04 <mickeyl> although i agree that fixing it in the first place would be better
Apr 19 12:16:23 <DocScrutinizer> mickeyl: work around a memleak sounds like 80% info needed for a fix
Apr 19 12:16:47 <mickeyl> good
Apr 19 12:17:19 <DocScrutinizer> what's this workaround looking like?
Apr 19 12:18:19 * DocScrutinizer hopes it's not powercycling modem ;)
Apr 19 12:18:44 <mickeyl> honoring the FC status
Apr 19 12:18:53 <DocScrutinizer> FC?
Apr 19 12:19:09 <alphaone> mickeyl: That sounds more like a fix than a work around...
Apr 19 12:19:10 <mickeyl> in muxer mode, the modem sets the FC bit on a virtual channel, if it gets overloaded
Apr 19 12:19:17 <alphaone> flow control
Apr 19 12:19:25 <mickeyl> if you continue hammering the modem, it seems to crash
Apr 19 12:19:33 <DocScrutinizer> duh, that's a fix
Apr 19 12:19:42 <mickeyl> i'm not so sure... the modem should _never_ crash
Apr 19 12:19:49 <mickeyl> even if you insist on hammering it
Apr 19 12:19:51 <mickeyl> IMO
Apr 19 12:19:54 <DocScrutinizer> amazing, it doesn't like this treatment? ;)
Apr 19 12:20:13 <DocScrutinizer> yup, ack
Apr 19 12:20:23 <alphaone> mickeyl: Doesn't the muxer spec say you need to honor the fc bit?
Apr 19 12:20:34 <mickeyl> alphaone: let me check
Apr 19 12:20:50 <alphaone> mickeyl: I agree it shouldn't crash.
Apr 19 12:21:11 <alphaone> But the alternative would be that the modem just drops the bytes it can't handle
Apr 19 12:21:14 <alphaone> IMHO
Apr 19 12:21:24 <DocScrutinizer> anyway with muxer there's few sense in hw-flowcontrol
Apr 19 12:21:28 <alphaone> That would also not help us
Apr 19 12:22:03 <DocScrutinizer> so for sure there needs to be some sw-flowctl
Apr 19 12:22:30 <mickeyl> 07.07 says 'data may not be transferred'
Apr 19 12:22:43 <mickeyl> and FC signalling is optional anyways ...
Apr 19 12:22:45 <lindi-> got through airport security check :)
Apr 19 12:22:48 <DocScrutinizer> MAY NOT i guess
Apr 19 12:23:03 <DocScrutinizer> lindi-: hehe
Apr 19 12:23:08 <DocScrutinizer> lindi-: problems?
Apr 19 12:23:23 <lindi-> none so far
Apr 19 12:24:00 <dos1> Blu3: you can fix timestamp, but implementing custom way to store messages is a bad way to do it
Apr 19 12:24:14 <budfive> mickeyl: ok. it hapenned again (3 for 3)
Apr 19 12:24:20 <budfive> mickeyl: i'm gdb-ing ppp
Apr 19 12:24:20 <dos1> Blu3: implement deleting messages in opimd and use it. it works ok (except deleting ofc :P)
Apr 19 12:25:03 <DocScrutinizer> dos1: mickeyl: apropos timestamp. I think we should set RTC of modem on init
Apr 19 12:25:13 <mickeyl> got your bug report
Apr 19 12:25:32 <DocScrutinizer> mickeyl: what do you think?
Apr 19 12:25:45 <mickeyl> you don't have an email set in trac?
Apr 19 12:25:48 <mickeyl> i already commented
Apr 19 12:25:50 <budfive> mickeyl: ppp is in disconnect_tty() which calls set_up_tty(), which never finishes. 
Apr 19 12:26:07 <DocScrutinizer> hm, probably not. let me see
Apr 19 12:26:30 <budfive> mickeyl: also abyss is redlining the cpu, probably being called from ppp in an infinite loop
Apr 19 12:26:56 <mickeyl> budfive: possible, yeah
Apr 19 12:27:25 <budfive> mickeyl: let me see if i can gdb abyss. should be possible to gdb vala programs, right? It's just C on some level, no?
Apr 19 12:27:30 <mickeyl> correct
Apr 19 12:27:36 <mickeyl> it's C
Apr 19 12:30:21 <PaulFertser> alphaone: why don't you close #395? There's already an interface implemented. The only problem left is to switch between powered and unpowered usb hostmodes.
Apr 19 12:31:15 <alphaone> PaulFertser: Close it if you want..
Apr 19 12:31:23 <alphaone> I wasn't aware of the interface
Apr 19 12:32:24 <dos1> alphaone: that interface is there for a really long time ;x
Apr 19 12:32:43 <alphaone> okay, great :-)
Apr 19 12:32:57 <alphaone> I never needed it
Apr 19 12:33:02 <Ainulindale> neobaka: New kernel is here
Apr 19 12:33:48 <neobaka> great ^^
Apr 19 12:33:55 <Ainulindale> (in unstable)
Apr 19 12:34:06 <neobaka> i'm still testing with Qi, no wsod up to now
Apr 19 12:34:17 <Ainulindale> well it's been patched by mwester 
Apr 19 12:34:39 <dos1> i would like to see #396 implemented
Apr 19 12:34:43 <dos1> (FSO)
Apr 19 12:37:12 <budfive> mickeyl: i got the -dbg packages for abyss and libgsm*. 
Apr 19 12:37:30 <budfive> mickeyl: seems that even with ppp paused in gdb, abyss is still using all available cpu
Apr 19 12:38:02 <budfive> mickeyl: _transport_actionCallback is being called repeatedly
Apr 19 12:38:59 <onen> DocScrutinizer: grüezzi
Apr 19 12:39:34 <DocScrutinizer> moinmoin, onen
Apr 19 12:39:51 <mickeyl> budfive: this means the FC bit is set 
Apr 19 12:39:54 * DocScrutinizer away now, well in 5min
Apr 19 12:39:57 <mickeyl> well, wait
Apr 19 12:39:58 <mickeyl> no
Apr 19 12:40:05 <mickeyl> we clean the watch, if the FC bit is set
Apr 19 12:40:09 <onen> DocScrutinizer: I work on activation of my beta code about neighbour logging
Apr 19 12:40:19 <DocScrutinizer> cool
Apr 19 12:40:20 <mickeyl> can you dump the variables?
Apr 19 12:40:28 <mickeyl> like, the condition 
Apr 19 12:40:36 <mickeyl> whether it's IN or HUP
Apr 19 12:40:54 <onen> DocScrutinizer: I take the signal strength percent from framework GetStatus() and translate it to dbm, for the serving.
Apr 19 12:40:55 <budfive> mickeyl: hold on. as an experiment, i SIGKILL'ed pppd to see what would happen to abyss
Apr 19 12:41:29 <budfive> mickeyl: it still runs red, but differently. in THAT case it's in a infinite poll() loop
Apr 19 12:41:31 <DocScrutinizer> onen: you also log TA?
Apr 19 12:41:33 <onen> DocScrutinizer: I want to find the same value with neighbours. http://wiki.openmoko.org/wiki/Neo_1973_and_Neo_FreeRunner_gsm_modem#Serving_Cell_Information_.282.2C1.29 says: rxlev 	 Received Field Strength 	 (rxlev/2)+2 gives the AT+CSQ response value 
Apr 19 12:41:53 <onen> DocScrutinizer: not yet. TA is valid only for serving, IIRC?
Apr 19 12:42:01 <DocScrutinizer> yup
Apr 19 12:42:08 <budfive> mickeyl: let me get back to the state where pppd is hung, and i'll give you a variable dump
Apr 19 12:42:08 <tmzt> ppp sets up the ldisc and does lcp/ipcp/etc right? kernel still generates ppp frames?
Apr 19 12:42:34 <budfive> mickeyl: does this not happen for you? all i'm doing is loading a website with gprs
Apr 19 12:42:36 <onen> DocScrutinizer: I wanted to know if this is for sure valid? (I have tested it, and it seems to be right). Is it only for this modem, or will this formula always be valid?
Apr 19 12:42:50 <mickeyl> budfive: no it works fine here, like i commented on the bug, i can't get it to crash, even with latimes
Apr 19 12:42:58 <DocScrutinizer> no idea, sorry
Apr 19 12:43:21 <mickeyl> tmzt: yeah, we only use ppp for lcp/icpc handshake and forwarding packages. i'd love to get away without
Apr 19 12:43:26 <onen> DocScrutinizer: damn. :-( do you have any idea whom I may ask?
Apr 19 12:43:55 <tmzt> mickeyl: abyss mux and ppp are simlar protocols?
Apr 19 12:43:56 <DocScrutinizer> well neighbour cell info is nonstandard anyway
Apr 19 12:44:02 <tmzt> 0710
Apr 19 12:44:07 <mickeyl> tmzt: no, not at all
Apr 19 12:44:11 <mickeyl> abyss is 0710
Apr 19 12:44:17 <mickeyl> ppp is hdlc
Apr 19 12:44:26 <tmzt> but both hdlc-like?
Apr 19 12:44:32 <mickeyl> yeah
Apr 19 12:44:32 <mickeyl> a bit
Apr 19 12:44:50 <mickeyl> it's completely sick, if you think about it
Apr 19 12:45:00 <mickeyl> the path to use ppp over mux is travelling kernel/userland 4 times
Apr 19 12:45:01 <onen> DocScrutinizer: ok. will put big warning and comments in source code then. Our purpose if anyway to provide same quantity effect as other projects, but with time we want to replace neighbour data by serving one, which seems safer
Apr 19 12:45:01 <mickeyl> or more
Apr 19 12:45:07 <DocScrutinizer> onen: so this is a question probably nobody can answer
Apr 19 12:45:28 <onen> s/if/is/
Apr 19 12:45:28 <bzzbot> onen meant: DocScrutinizer: ok. will put big warning and comments in source code then. Our purpose is anyway to provide same quantity effect as other projects, but with time we want to replace neighbour data by serving one, which seems safer
Apr 19 12:45:31 <mickeyl> i need a small ppp library to handle this protocol on my own
Apr 19 12:45:37 <mickeyl> but there is nothing like that
Apr 19 12:46:05 <tmzt> I know there a some kernel drivers that do ppp directly by sending frames to another part of the kernel
Apr 19 12:46:10 <onen> DocScrutinizer: thanks for your help. I TA is on my todo list :-)
Apr 19 12:46:24 <DocScrutinizer> np
Apr 19 12:46:28 <tmzt> but you still have mux in userspace so that doesn't really gain anything
Apr 19 12:46:35 <mickeyl> right
Apr 19 12:46:48 <mickeyl> the thing is
Apr 19 12:46:52 <mickeyl> if i had a ppp library
Apr 19 12:46:56 <mickeyl> we could save 2 transfers
Apr 19 12:47:03 <mickeyl> since we don't need two pts
Apr 19 12:47:18 <mickeyl> but can read directly from the modem and hand out the frames
Apr 19 12:47:34 <tmzt> there's also the possibility of writing a ppp plugin that would use a socket to talk with abyss
Apr 19 12:47:48 <tmzt> which could inject the frames
Apr 19 12:47:49 <mickeyl> true. still that doesn't remove the nightmare of controlling external processes
Apr 19 12:48:22 <mickeyl> given that ppp contains all the dozens of things we don't use
Apr 19 12:49:58 <tmzt> maybe the qemu version of the userland ppp stack would work
Apr 19 12:50:11 <tmzt> can't think of what it's called
Apr 19 12:50:48 <tmzt> I mean the one qemu used, not the qemu version which doesn't use ppp
Apr 19 12:51:16 <tmzt> slirp
Apr 19 12:51:39 <mickeyl> hmm, yeah
Apr 19 12:52:05 <mickeyl> all i really need is LCP and ICPC setup and managing the network device
Apr 19 12:52:13 <mickeyl> the rest is done by the kernel already
Apr 19 12:53:19 <mickeyl> bbiab
Apr 19 12:54:32 <budfive> mickeyl: so i just hit the bug again (4 for 4). It seems abyss begins to redline the cpu before detach() is called
Apr 19 12:54:42 <budfive> mickey|sun: which variable do you want?
Apr 19 12:55:49 <mickey|sun> condition
Apr 19 12:56:45 <budfive> mickey|sun: hmmm. that's not in "info variables"
Apr 19 12:57:15 <budfive> mickey|sun: maybe it's been optimized out.
Apr 19 12:57:23 <budfive> mickey|sun: is it local to a function?
Apr 19 13:12:28 <Gorbusch> hi
Apr 19 13:12:44 <Gorbusch> anyone using navit with shr?
Apr 19 13:14:53 <budfive> mickey|sun: before i send any signals to pppd, condition in _transport_actionCallback is IN
Apr 19 13:16:13 <neobaka> Ainulindale: the new kernel doesn't solve the issue
Apr 19 13:17:01 <budfive> mickey|sun: if I SIGTERM pppd, condition in _transport_actionCallback is also IN
Apr 19 13:18:18 <budfive> mickey|sun: if I SIGKILL pppd, _transport_actionCallback is no longer called
Apr 19 13:20:52 <dos1> spaetz: ping
Apr 19 13:21:32 * Q-Master tired of compiling arm gcc for powerpc linux
Apr 19 13:22:30 <dos1> what i want to see in SHR-dos image:
Apr 19 13:22:39 <dos1> - x11-16 used by default in e and in elementary
Apr 19 13:23:02 <dos1> pCalc on desktop renamed to Calc or Calculator
Apr 19 13:23:25 <dos1> numptyphysics - Numpty Physics
Apr 19 13:23:56 <dos1> top shelf animation - very fast
Apr 19 13:24:05 <dos1> clock in hidden gadgets instead of visible gadgets
Apr 19 13:25:18 <neobaka> why that?
Apr 19 13:25:25 <dos1> very simple splash screen - maybe some very tiny progress bar on center of screen, without any logo
Apr 19 13:25:41 <dos1> and better first boot wizard - e one sucks ;p
Apr 19 13:26:08 <dos1> and that's all
Apr 19 13:26:19 <dos1> neobaka: why what?
Apr 19 13:27:09 <dos1> oh, and /etc/network/interfaces modified
Apr 19 13:27:11 * neobaka wants to see the clock
Apr 19 13:27:30 <dos1> ip for usb0 - from 192.168.0.202 to 192.168.2.202
Apr 19 13:27:47 <dos1> neobaka: i like clock on center of hidden gadgets
Apr 19 13:28:00 <dos1> one click and i can see clock
Apr 19 13:28:20 <dos1> smaller font in lancher would be good too
Apr 19 13:29:06 <neobaka> thats two clicks: one to wake up/un"black" the screen and one for pulling down the bar; plus the one to rise it again. 
Apr 19 13:29:45 <dos1> neobaka: for time when neo is blanked i have watch on my hand ;)
Apr 19 13:29:58 <neobaka> i don't. since years
Apr 19 13:30:11 <dos1> and i'm talking about my preferences
Apr 19 13:30:16 <dos1> people can agree or not :)
Apr 19 13:30:25 <neobaka> i don't ^^
Apr 19 13:30:31 <dos1> i can set all of those by default, as i have access
Apr 19 13:30:40 <dos1> but i know that many people will don't agree with me
Apr 19 13:30:44 <dos1> so i'm not doing it ;)
Apr 19 13:33:09 <neobaka> mwester: the new kernel patch doesn't solve the WSoD issue
Apr 19 13:34:29 <dos1> and i would like to see another file manager
Apr 19 13:34:53 <bumbl> dos1: i agree with everything except /etc/networks/interfaces and the clock
Apr 19 13:35:18 <bumbl> + i want to have suspend on short power press
Apr 19 13:35:24 <neobaka> i wish the image had a working vagalume ^^ that's all
Apr 19 13:35:45 <dos1> bumbl: so fine, as that two are my very individual choices ;)
Apr 19 13:36:07 <bumbl> + working aux lock
Apr 19 13:36:15 <bumbl> + faster app startup
Apr 19 13:36:22 <dos1> suspend - disagree, i like that illume window
Apr 19 13:36:29 <dos1> aux lock - +1
Apr 19 13:36:56 <bumbl> dos1: the illume window has a major problem: suspend takes longer with it
Apr 19 13:37:06 <bumbl> and you can't suspend without looking on the screen
Apr 19 13:37:39 <dos1> suspending without looking on the screen i have after timeout ;)
Apr 19 13:37:53 <bumbl> dos1: yes i have a timeout too
Apr 19 13:37:55 <dos1> and i like to have close and home buttons on power button
Apr 19 13:38:10 <bumbl> you have them in illume shelf
Apr 19 13:38:20 <bumbl> as fast as with the power button
Apr 19 13:38:30 <bumbl> one click -> home and close
Apr 19 13:38:53 <bumbl> one press -> menu -> suspend could be done faster with one press -> suspend
Apr 19 13:39:29 <dos1> bumbl: even with full screen apps? ;)
Apr 19 13:40:05 <dos1> that tiny splash screen maybe could be done with splashy?
Apr 19 13:40:11 <bumbl> dos1: for that we could have short press -> suspend; long press -> menu; extra long press -> power down
Apr 19 13:40:23 <neobaka> ah, another wish: better scrolling on the home screen (i alwasy end up clicking sth. >.<)
Apr 19 13:40:41 <dos1> neomaka: you can set up sensitivity of finger scrolling
Apr 19 13:40:44 <bumbl> + if possible no splashscreens at all everywhere
Apr 19 13:40:52 <bumbl> as this just slows things down
Apr 19 13:41:50 <dos1> bumbl: but i want to see progress. we have loglevel=1 in GTA02-append
Apr 19 13:42:00 <dos1> and i can't see anything :x
Apr 19 13:42:05 <dos1> oh, i have idea
Apr 19 13:42:19 <dos1> maybe some text-based progressbar? :D
Apr 19 13:42:28 <bumbl> yes
Apr 19 13:42:34 <bumbl> that would be an option
Apr 19 13:42:41 <bumbl> but printks are slow too
Apr 19 13:42:53 <sepultina> hello, why are the new unstable image so big? Is this only for the locale-file?
Apr 19 13:43:00 <dos1> tiny ascii progressbar
Apr 19 13:43:05 <dos1> on center of screen
Apr 19 13:43:16 <dos1> very small
Apr 19 13:44:02 <dos1> prints not after every operation
Apr 19 13:44:10 <dos1> only after 10% of booting
Apr 19 13:44:18 <bumbl> well
Apr 19 13:45:00 <bumbl> it would be optimal if boot would only take ~10s to e
Apr 19 13:45:22 <bumbl> as this would mean - no need for nothing
Apr 19 13:45:35 <dos1> heh
Apr 19 13:45:38 <dos1> but how?
Apr 19 13:45:56 <dos1> booting from sdcard and using nand for suspend-to-disk?
Apr 19 13:46:02 <thseiler_> good morning, i have a rather strange thing here with the do_fetch of linux-openmoko-2.6.28 when building fso milestone 5.5. log sais: git fetch git://git.openmoko.org/git/kernel.git anty-tracking failed with signal 128, output: fatal: not a git repository...       Shouldn't that be a git clone instead of a git fetch ? How can i change that in the SRC_URI of bb ? thanks !
Apr 19 13:47:17 <bumbl> dos1: build in an turbo booster
Apr 19 13:47:19 <bumbl> ;)
Apr 19 13:47:34 <thseiler_> dos1: tests showed that the troughput of NAND and sd cars is comparable...
Apr 19 13:47:42 <bumbl> nah it would help to use an embedded init system
Apr 19 13:48:16 <dos1> thseiler_: no, i'm not talking about that. i mean suspend to disk
Apr 19 13:48:24 <dos1> we are using now only suspend to ram
Apr 19 13:48:29 <thseiler_> sd looses because every byte that goes to/from sd has to pass trough the glamo, thats an additional copy...
Apr 19 13:48:40 <thseiler_> dos1: ah, but it will be even slower
Apr 19 13:49:03 <dos1> heh
Apr 19 13:49:11 <bumbl> e.g. einit is damn fast (but dead, there will be an successor)
Apr 19 13:49:51 <bumbl> or initng
Apr 19 13:50:05 <dos1> initng on neo processor?
Apr 19 13:50:13 <dos1> it's damn fast on pc, i agree
Apr 19 13:50:20 <dos1> but how fast it would be on neo?
Apr 19 13:50:36 <bumbl> or openrc (which does not use any new ideas but makes sysvinit damn fast too)
Apr 19 13:50:43 <bumbl> dos1: that we have to find out
Apr 19 13:51:00 <bumbl> einit was desinged for embedded use
Apr 19 13:54:26 <bumbl> (on the desktop (i know the neo is not a desktop) the bios, grub and the kernel take 3 times the time openrc needs to boot into x)
Apr 19 13:57:37 <tnc> hey there :)
Apr 19 13:58:47 <tnc> what do you think about a flashing led if you have a missed call or message? it should work even in suspend
Apr 19 13:59:48 <dos1> tnc: so do that
Apr 19 13:59:53 <dos1> ]:->
Apr 19 14:00:01 <dos1> flashing led in suspend isn't possible
Apr 19 14:00:11 <dos1> it can be turned on or off. not blinking.
Apr 19 14:00:36 <dos1> and... firstly you have to figure out, if you have a missed call or message
Apr 19 14:00:37 <tnc> it was just an idea, i have not the programming knowledge :(
Apr 19 14:01:01 <tmzt> it's not a programming issue
Apr 19 14:01:02 <dos1> for now only pyphonelog allows that.
Apr 19 14:01:28 <dos1> we have to use opimd for doing it
Apr 19 14:01:37 <tnc> ah, i understand
Apr 19 14:01:46 <dos1> and... write opimd code to support it ;D
Apr 19 14:01:58 <tnc> ;D
Apr 19 14:03:04 <tnc> are you @ essen in may?
Apr 19 14:03:22 <dos1> I?
Apr 19 14:03:31 <tnc> http://shr.bearstech.com/trac/wiki/FSOSHRUDCON%2709
Apr 19 14:04:06 <dos1> if you are talking to me - no :(
Apr 19 14:04:20 <tnc> yes, i was talking to you :)
Apr 19 14:04:56 <tnc> might be interesting for me
Apr 19 14:05:25 <dos1> unfortunately i can't be there :(
Apr 19 14:05:34 <tnc> too far away?
Apr 19 14:07:52 <bumbl> i'd guess too far away + too expensive + better things to do
Apr 19 14:08:28 <tnc> not that bad arguments not to be there :-/
Apr 19 14:08:33 <tnc> :D
Apr 19 14:09:04 <bumbl> (my arguments) ;)
Apr 19 14:09:38 <bumbl> (+ not affiliated with shr or fso) but this does not apply for dos1 
Apr 19 14:10:16 <tnc> bumbl you using the "standard" openmoko distribution?
Apr 19 14:11:04 <bumbl> tnc: well at the moment i use shr (although from the concept i like pyneo + epydial or paroli more)
Apr 19 14:11:36 <bumbl> but i have not contributet anything to shr or fso except for a .bb for my app
Apr 19 14:12:03 <DocScrutinizer> dos1 mustn't come to fsoshrcon. Ainulindale forbid ;)
Apr 19 14:13:02 <bumbl> haha
Apr 19 14:13:13 <tnc> bumbl: ah, rgr that. me too, i uploaded my screen to the openmoko wiki and updated the wiki a bit. for me i dont like the om2008 interface at all, 2007 looked *much* better than 2008. but thats only my opinion
Apr 19 14:13:40 <bumbl> om2008 is horrible
Apr 19 14:14:49 <alphaone> only zhone is the One True Interface
Apr 19 14:14:55 <tnc> bumbl: of course...nothing good
Apr 19 14:14:56 <alphaone> zhone is awesome!
Apr 19 14:15:10 <alphaone> feature complete, stable, fast
Apr 19 14:15:13 <bumbl> zhone is nice
Apr 19 14:15:19 <bumbl> but not feature complete
Apr 19 14:15:21 <bumbl> imo
Apr 19 14:15:22 <alphaone> especially fast
Apr 19 14:15:26 <alphaone> ;-)
Apr 19 14:15:31 <alphaone> bumbl: <irony>/
Apr 19 14:15:35 <bumbl> hehe
Apr 19 14:15:46 <alphaone> s:>/:/>:
Apr 19 14:15:50 <bumbl> + zhone seems not to suffer from the
Apr 19 14:15:54 <alphaone> hmm
Apr 19 14:15:54 <tnc> alpha: right, zphone is really nice... but i cant really remember if it works for me, i have the famous gsm oscillating bug
Apr 19 14:16:09 <alphaone> tnc: fso is working around that 
Apr 19 14:16:13 <bumbl> take up call but ringing goes on for some seconds bug
Apr 19 14:16:13 <alphaone> shr as well
Apr 19 14:16:17 <bumbl> shr is facing
Apr 19 14:16:25 <alphaone> bumbl: Oh, it does
Apr 19 14:16:33 <alphaone> It's an oeventsd problem
Apr 19 14:16:38 <tnc> yes, shr is working like a charm
Apr 19 14:16:41 <bumbl> alphaone: ah ok
Apr 19 14:16:46 <bumbl> it didn't when i last tried it
Apr 19 14:17:05 <alphaone> bumbl: Yeah, some races got fixed which increased the delay...
Apr 19 14:17:23 <bumbl> alphaone: you confused up bzzbot 
Apr 19 14:17:26 <bumbl> s
Apr 19 14:17:32 <bumbl> s#up##
Apr 19 14:17:45 <alphaone> hehe
Apr 19 14:17:52 <alphaone> s/e/a/
Apr 19 14:17:52 <bzzbot> alphaone meant: hahe
Apr 19 14:17:58 <alphaone> still works
Apr 19 14:18:04 <alphaone> only with / though
Apr 19 14:18:13 <tnc> for some months shr is suitable for every day use (for me)
Apr 19 14:18:18 <bumbl> a
Apr 19 14:18:18 <alphaone> s/\//'\/'/
Apr 19 14:18:21 <CIA-75> freesmartphone.org: 03nytowl 07framework * rba6708abf2b9 10/framework/subsystems/otimed/otimed.py: otimed: apply patch from Angus to handle CTZV messages
Apr 19 14:18:22 <bumbl> s#a#a#
Apr 19 14:18:29 <bumbl> yep
Apr 19 14:18:32 <DocScrutinizer> and it doesn't like ;
Apr 19 14:18:50 <alphaone> DocScrutinizer: Oh, do I smell an exploit vector?
Apr 19 14:18:57 <DocScrutinizer> yup
Apr 19 14:19:03 <DocScrutinizer> thimk so
Apr 19 14:19:08 <alphaone> s/vector;echo hello
Apr 19 14:19:11 <DocScrutinizer> s/m/n/
Apr 19 14:19:12 <bzzbot> DocScrutinizer meant: think so
Apr 19 14:19:35 <bumbl> tnc: shr lacks a) opimd (but that do all except for pyneo)
Apr 19 14:19:41 <bumbl> b) speed
Apr 19 14:20:06 <bumbl> and c) big button keyboard
Apr 19 14:20:17 <bumbl> (which the other ones lack too)
Apr 19 14:20:48 <bumbl> rebooting
Apr 19 14:20:49 <tnc> speed? with qi its quite usable...not slower than my old nokia phone with symbian. for me i like the small qwerty keyboard more than the big ones
Apr 19 14:21:03 <bumbl> tnc: app starting takes ages
Apr 19 14:21:10 <bumbl> b in 2min
Apr 19 14:23:41 <DocScrutinizer> b not starting here at all ;-)
Apr 19 14:24:10 <tnc> b?
Apr 19 14:24:20 <tnc> do i have missed anything :D
Apr 19 14:24:33 <DocScrutinizer> [2009-04-19 16:21:04] <bumbl> tnc: app starting takes ages
Apr 19 14:24:35 <DocScrutinizer> [2009-04-19 16:21:12] <bumbl> b in 2min
Apr 19 14:25:50 <tnc> for me its not much slower than my old nokia 6600 phone...?
Apr 19 14:27:04 <tnc> strange
Apr 19 14:27:07 <alphaone> probably because of:
Apr 19 14:27:07 <alphaone> thebe buzz-mailin # b
Apr 19 14:27:08 <alphaone> bash: b: command not found
Apr 19 14:27:39 <tnc> what is b? i`m confused
Apr 19 14:28:20 <tmzt> bb - be back
Apr 19 14:28:58 <tnc> yes, but they spoke about a program? probable i just need sleep :D
Apr 19 14:29:08 <tnc> wb bumbl
Apr 19 14:29:26 <bumbl> thank you
Apr 19 14:29:59 <bumbl> took longer than expected /me should not forget adding a new kernel to menu.lst + installing nvidia-drivers after that
Apr 19 14:30:26 <tnc> vesa is enough xD
Apr 19 14:32:39 <tnc> but what i expected, is that shr is getting faster and faster with nearly every release
Apr 19 14:34:02 <DocScrutinizer> tnc: heard of my secret plan to ge rich with aspirine shares ?  XD
Apr 19 14:34:20 <DocScrutinizer> geT
Apr 19 14:34:40 <tnc> doc: no, not until now, please tell me more xD
Apr 19 14:35:33 <DocScrutinizer> it's involving a TOASTER, plan B, and rumors about b taking infinitely to start. (the later one is a recent extension)
Apr 19 14:36:24 <tnc> xD
Apr 19 14:36:53 <DocScrutinizer> well, I stated even disclosing the secret plan is just another way to make it work, but today I'm not in the mood to elaborate on it ;)
Apr 19 14:38:35 <tnc> doc: but if you tell it in an public irc, its not secret anymore or will everybody get ill if they tell anybody about it...? aspirin will not help them :D
Apr 19 14:39:10 <onen> shoragan: ping
Apr 19 14:39:19 <shoragan> pong
Apr 19 14:39:20 <DocScrutinizer> you'll get ill by mere thinking f it
Apr 19 14:39:25 <onen> shoragan: hallo
Apr 19 14:39:32 <shoragan> hi :)
Apr 19 14:39:39 <admiral0> hi, does bloetooth work in shr-testing?
Apr 19 14:39:45 <tnc> hi :)
Apr 19 14:40:34 <tnc> admiral: cant tell that, i do not use it.. :(
Apr 19 14:40:52 <onen> shoragan: did you have time to think about my comments on the implementation of location in FSO (the sqlite files we have started to set up)? And more generaly, did you follow the thread about collaboration between the GSM/GPS projects? (there is another one started today on community list)
Apr 19 14:41:24 <admiral0> tnc: hidd dev does not show anythng
Apr 19 14:41:26 <admiral0> :S
Apr 19 14:42:31 <tnc> wait a sec, i will try to send a file from my old phone to the freerunner
Apr 19 14:43:14 <shoragan> onen, i didn't see the new thread yet
Apr 19 14:43:15 * DocScrutinizer runs to get away from community-ml before it's gettin dark outside
Apr 19 14:43:26 <shoragan> and i din't know about the sqlite file either
Apr 19 14:45:56 <tnc> admiral: my old phone finds the neo, but when i try to send it says it cant connect
Apr 19 14:46:12 <admiral0> obexftpd is running?
Apr 19 14:46:58 <onen> shoragan: well I wrote an email to you where I spoke about the sqlite file. And you answered on the ML under the thread "three databases for gsm location" ...
Apr 19 14:47:05 <tnc> dunno, just went to the settings and turned bluetooth+visibility on
Apr 19 14:47:31 <onen> shoragan: We already did some work on exporting the database under SQLite files for every country. And on top of this, a small DBus service to bring the localisation to everyone... 
Apr 19 14:47:50 <admiral0> /etc/init.d/obexftpd start
Apr 19 14:48:29 <shoragan> onen, i didn't use sqlite because of the size
Apr 19 14:48:34 <admiral0> /etc/init.d/opd start
Apr 19 14:48:57 <shoragan> as i wanted to have a global db on the device
Apr 19 14:48:58 <tnc> admiral: i`ll try that
Apr 19 14:49:09 <shoragan> or at least continent-wide
Apr 19 14:49:11 <gurugentoo> is the apr 19 unstable image usable?
Apr 19 14:49:16 <onen> shoragan: size? did you put every data from cellhunter in it, or only a part of it?
Apr 19 14:49:32 <shoragan> it contains every cell from cellhunter
Apr 19 14:49:40 <Sharwin_F> gurugentoo, yesterday night I upgraded unsable and works, upgrading now, I'll tell you when it finishes :P
Apr 19 14:49:54 <onen> shoragan: Nick did some evaluation, and a database of gsm cell id (not raw data) would be 2-3 MB iirc
Apr 19 14:50:11 <gurugentoo> Sharwin_F: awesome
Apr 19 14:50:22 <shoragan> onen, for which dataset?
Apr 19 14:50:25 <onen> shoragan: we build sqlite files per country and per operator
Apr 19 14:51:16 <onen> shoragan: Nick that is an evaluation based on the number of antenna (and or cells, Nick knows this better than me), for a country like France
Apr 19 14:51:24 <shoragan> onen, your site seems down
Apr 19 14:52:15 <onen> shoragan: damn, indeed. We host it on personnal pages from the internet provider free.fr. I will let Nick know
Apr 19 14:52:25 <Sharwin_F> tnc, I think you have to install obexftp, it doesn't come by default: opkg install obexftp
Apr 19 14:52:43 <tnc> ah, right, will try that first
Apr 19 14:52:56 <onen> shoragan: our approach was to be able to update databases on phones easily, through standard packages.
Apr 19 14:53:02 <shoragan> onen, is your server side code available somewhere?
Apr 19 14:53:20 <Sharwin_F> then you should have another label on shr-settings called obexftp or something similar, under visibility
Apr 19 14:53:21 <shoragan> yes. that would be nice
Apr 19 14:53:51 <shoragan> but i don't want to travel somewhere and have to install all the packages beforehand
Apr 19 14:54:07 <shoragan> complete cellhunter db is about 800 k
Apr 19 14:54:17 <shoragan> and thats with coordinates as doubles
Apr 19 14:54:22 <onen> shoragan: AFAIK yes. Nick put it on the sourceforge page: http://sourceforge.net/project/showfiles.php?group_id=218065
Apr 19 14:55:01 <shoragan> the mapping manager?
Apr 19 14:55:10 <onen> shoragan: I do not work on it. So you should ask him directly. better per email. do you want me to send a first email between you, him and I?
Apr 19 14:55:31 <shoragan> i could offer you hosting for that stuff, if need
Apr 19 14:56:56 <Sharwin_F> gurugentoo, it looks like working :)
Apr 19 14:57:03 <onen> shoragan: to my opinion, that would be great. But to be honnest, I prefer Nick to tell, because he takes care of the server side, and he may find it easier to keep it where it is (but again, we should talk about it)
Apr 19 14:57:11 <Sharwin_F> at least upgrading with opkg upgrade
Apr 19 14:57:19 <shoragan> onen, does nick use irc?
Apr 19 14:57:30 <onen> shoragan: not that I am aware of
Apr 19 14:57:56 <onen> shoragan: that is why I proposed to initiate the talk per email between you both
Apr 19 14:58:02 <shoragan> ok, sure
Apr 19 14:58:02 <onen> shoragan: do you want me to?
Apr 19 14:58:19 <shoragan> did you look at geoclue?
Apr 19 14:58:58 <shoragan> before doing our own dbus api, maybe we should extend that
Apr 19 15:00:40 <onen> shoragan: I did once. But to give you a better view of where I stand with the dbus location service: Nick builds the sqlite files (lac positions, cid, positions). I have started some code together to show how this could be used. But this is in no way a real localisation service, deeply thought. I see it more as sth which could plug into your code, for example
Apr 19 15:01:28 <shoragan> onen, do you have a svn/git repo somewhere?
Apr 19 15:01:54 <onen> shoragan: I have, but for my part, the client logger. Nick does not have a public one, AFAIK
Apr 19 15:02:06 <shoragan> did you look at the hack i did at openexpo?
Apr 19 15:02:21 <shoragan> i mean for the code you started
Apr 19 15:02:36 <onen> shoragan: that is the reason I want to get you both in touch. I don't want to talk for Nick, and say sth wrong. I prefer you to ask him directly
Apr 19 15:03:27 <onen> shoragan: I had started before this. and so far, my code is able to run as a dbus service, and does not even query the sqlite file. so you are far more advanced as I am.
Apr 19 15:04:29 <onen> shoragan: I had a look after seeing the git commits, and guessed you used cellhunter data. I then talked with Stefan to know if cellhunter was the "official" provider for the framework, and if our arguments about quality were considered interesting
Apr 19 15:04:52 <shoragan> i just used cellhunter because i've been mapping for it
Apr 19 15:04:58 <shoragan> and know where to get the DB
Apr 19 15:05:28 <shoragan> so there is no official provide
Apr 19 15:06:08 <onen> shoragan: then Stefan started the thread to see if collaboration was possible. To my view: cellhunter does not want to collaborate on code (he answered privately to me: I want to keep control of my database. for client side, I proposed to trash my code and put his in a git repository and start working together, he sais he is not interested). for him collaboration means sharing data.
Apr 19 15:06:26 <shoragan> :/
Apr 19 15:06:44 <alphaone> This is just sad
Apr 19 15:07:22 <onen> shoragan: yes, I know that no decision has been made. and as you may have seen on the thread started by Sterfan. Opencellid, did not even answer the questions about modifying his database. he only wants us to fill it. and cellhunter share the view of a big database, the biggest possible
Apr 19 15:07:32 <shoragan> let me catch up the the thread on communtity
Apr 19 15:07:56 <onen> alphaone: was your comment about what I wrote about cellhunter?
Apr 19 15:08:07 <onen> shoragan: there is not much there
Apr 19 15:08:20 <alphaone> onen: If their not interested then we'll need to merge the data ourselves
Apr 19 15:08:25 <alphaone> The licenses allow for it
Apr 19 15:08:32 <alphaone> onen: yes
Apr 19 15:09:07 <onen> shoragan: Nick did some import of oepncellid, we found some garbage data in it (cell id or lac id which were 9 digits or so, cannot remember exaclty, Nick will know better)
Apr 19 15:09:56 <shoragan> onen, cellhunter also has some garbage data
Apr 19 15:10:23 <shoragan> those should be filtered out when building a file/db for end-users
Apr 19 15:10:32 <onen> alphaone: yes very sad to me. but I think I cannot propose more than trashing my code! by the way, this was all on private email, and now I would have refused it, because this is not public :-(
Apr 19 15:10:54 <alphaone> onen: Yeah...
Apr 19 15:10:55 <shoragan> onen, is your db available for download somewhere?
Apr 19 15:11:05 <alphaone> I do see that you are trying your best to cooperate
Apr 19 15:11:14 <alphaone> sadly you seem to be the only one :-(
Apr 19 15:12:06 <rozzin> Eh? I thought that the idea behind cellhunter was to build an open DB of cell-site data--
Apr 19 15:12:07 <onen> shoragan: IIRC Nick told me a few days ago, that the data was not (at least publicly) available for download. I told him this is bad, and need to be done. you should ask him in the future email exanche (by the way, do you want it to be on oen of the mailing list, instead of privaely?)
Apr 19 15:13:01 <onen> alphaone: you only have my words (and now some public archive of th emailing list). you do not have the answer of cellhunter guy. So maybe I am lying ;-)
Apr 19 15:13:02 <rozzin> but he doesn't want to share the collected data with anyone? Eh?
Apr 19 15:13:22 <alphaone> onen: I'm sure you are ;-)
Apr 19 15:13:42 <onen> rozzin: well yes, what did I say which contradicts that?
Apr 19 15:13:50 <alphaone> But still I haven't heard much from him...
Apr 19 15:13:56 <shoragan> onen, i'm fine with either public or private, let nick decide
Apr 19 15:14:02 <CIA-75> freesmartphone.org: 03mickey 07framework * r76e76aaffd09 10/conf/example/frameworkd.conf: frameworkd.conf: document ti_calypso_muxer entry
Apr 19 15:14:03 <CIA-75> freesmartphone.org: 03mickey 07framework * rde49aac3b949 10/framework/patterns/processguard.py: patterns/processguard: introduce hadpid, so we have a handle to check for after a process ended
Apr 19 15:14:05 <CIA-75> freesmartphone.org: 03mickey 07framework * rac37c927b78f 10/ (ChangeLog framework/subsystems/odeviced/audio.py): 
Apr 19 15:14:05 <CIA-75> freesmartphone.org: odeviced: audio: introduce AlsaPlayer using aplay for wav playback.
Apr 19 15:14:06 <CIA-75> freesmartphone.org: This should improve playback latency, if e.g. a .wav is selected as ringtone.
Apr 19 15:14:07 <alphaone> shoragan: Huh?
Apr 19 15:14:07 <rozzin> So, this is... what, a repeat of CDDB?
Apr 19 15:14:24 <alphaone> public access to the data in the cell db is a must IMHO
Apr 19 15:15:01 <alphaone> And not only in the form of a query, but also as a dump
Apr 19 15:15:25 <shoragan> alphaone, private discussion, not db
Apr 19 15:15:25 <onen> rozzin: sorry missed your other comment. Cellhunter his very open on this, data is freely available. problems for us is: he does not care about quality, only quantity. second he wants to collaborate (collaborate means sharing data, but no work on code or sth) (this is my opinion!)
Apr 19 15:15:31 <rozzin> "The CellHunter Cell Database by Sebastian Hammerl is licensed under a
Apr 19 15:15:33 <rozzin> Creative Commons Attribution-Share Alike 3.0 Germany License."?
Apr 19 15:15:35 <alphaone> shoragan: ah, misunderstood
Apr 19 15:15:46 <rozzin> Ah.
Apr 19 15:16:17 <shoragan> we need to have some git repo for the server code
Apr 19 15:16:18 <onen> alphaone: I agree. data is contributed by people, and *must* be freely available to them
Apr 19 15:16:28 <alphaone> onen: Great :-)
Apr 19 15:16:28 <shoragan> so that we can collaborate on that code/db-layout too
Apr 19 15:16:49 <alphaone> What's the server written in btw?
Apr 19 15:16:52 <onen> shoragan: alphaone: ok sorry, you talked about the discussion
Apr 19 15:17:08 <admiral0> remoko does not work
Apr 19 15:17:11 <admiral0> :S
Apr 19 15:17:15 <alphaone> onen: No, I talked about db, shoragan talked about discussion
Apr 19 15:17:20 <mrmoku> onen: uploading not possible because site is offline? or because of some problem on my side... ?
Apr 19 15:17:25 <admiral0> ImportError: No module named remoko.remoko_server
Apr 19 15:17:35 <admiral0> i have remoko-server installed
Apr 19 15:17:36 <alphaone> admiral0: What version of bluez do you have?
Apr 19 15:17:42 <onen> alphaone: I think this is java + php for all the server side (Nick knows the details)
Apr 19 15:17:54 <shoragan> onen, neighbour cells are not 'less accurate' than serving cells
Apr 19 15:17:59 <alphaone> admiral0: oh, that's a different one then...
Apr 19 15:18:03 <admiral0> i have the one from testing repo
Apr 19 15:18:11 <shoragan> we need both for phones which can report both
Apr 19 15:18:15 <onen> alphaone: yes ok. but we all agree db public, discussion public or private, right?
Apr 19 15:18:28 <shoragan> onen, yes
Apr 19 15:18:29 <alphaone> onen: Ah, damn would have hoped it was rails :-)
Apr 19 15:18:38 <alphaone> onen: Yes, agreed
Apr 19 15:18:51 <onen> alphaone: opencellid code is ruby
Apr 19 15:19:08 <alphaone> hmm
Apr 19 15:19:08 <shoragan> do they have their code pulic?
Apr 19 15:19:12 <onen> shoragan: why your comment about neighbour cells?
Apr 19 15:19:16 <alphaone> iirc yes
Apr 19 15:19:25 <onen> shoragan: yes
Apr 19 15:20:07 <shoragan> onen, the serving cell is not always the stronges one, the network uses complex (and to us unpredictable) algorithms to decide when to do handovers
Apr 19 15:20:42 <shoragan> so we can't treat them equally, but still we can use that destinction to increase accuracy
Apr 19 15:21:09 <onen> shoragan: well I know this. do you say so because at a point in time 	I was stating that I thought it may not be interesting to log neighbours (or because our logger does not do it so far)?
Apr 19 15:21:23 <shoragan> also received power is not constant over time, the operators constanly tweak signal strengths and optimize their cell layoru
Apr 19 15:22:04 <onen> shoragan: because neighbour logging is beta code is last release. and I am currently finalizing it for next release
Apr 19 15:22:34 <shoragan> onen, somewhere you wrote about replacing neighbour measurements with serving ones when 'better' data is available
Apr 19 15:22:49 <onen> shoragan: agreed with signal strength. Thus this could allow us to map the cell coverage out of neighbours data, but filter the too low signals.
Apr 19 15:23:30 <shoragan> onen, signal strength is compareable between serving and neighbour
Apr 19 15:23:43 <shoragan> when in idle mode, they are measured the same way
Apr 19 15:24:32 <shoragan> so for coverage they should be equivalend
Apr 19 15:24:56 <onen> shoragan: ok got your point. my problem is that I get a signal strenght from the framework (GetStatus for example), which I can turn to dbm. the neighbour api gives me sth different. the wiki states that rxlev/2+2 == at CSQ. but DocScrutinizer told me he does not know if this is accurate or not
Apr 19 15:26:05 <shoragan> onen, you shouldn't try to calculate dBm, i think
Apr 19 15:26:10 <onen> shoragan: some tests seems to show this is to a couple of dbm accurate so far...
Apr 19 15:26:33 <shoragan> each modem will behave differently and even each deviced will have different antennas...
Apr 19 15:26:41 <onen> shoragan: because this fluctuates too much ?
Apr 19 15:27:01 <shoragan> it even changes some db's depending on how i hold the device
Apr 19 15:27:34 <shoragan> so i think it is interesting to look at releative signal strengths in *one* measurement
Apr 19 15:27:56 <shoragan> but all this is indepentant of the logging app
Apr 19 15:27:56 <onen> shoragan: well, Nick thinks he could make sth out of it. and our approach is to log too much instead of too little. If with time db becomes too big, and this data never turns to be useful for sth, we will be able to remove it
Apr 19 15:28:09 <shoragan> onen, exactly
Apr 19 15:28:49 <shoragan> don't convert measurements while logging
Apr 19 15:29:12 <shoragan> i saw that you record which device/model/version was used
Apr 19 15:29:25 <onen> shoragan: in februray Nick proposed to opencellid to merge our db in his, if he accepted to add our extra fields (hpv-dops, spead, heading, signal strength, etc...) this is in ML archive. we never got an answer
Apr 19 15:29:44 <shoragan> if conversion to dBm is useful, it still can be done later, leaving the reports unchanged
Apr 19 15:30:09 <onen> shoragan: he privately responded that he had thought about it, but that would not bring anything interesting. I asked if he had pointer at papers, and/or some tests results. I never got an answer
Apr 19 15:30:17 <shoragan> :/
Apr 19 15:31:37 <shoragan> i'd like to help you on the server side
Apr 19 15:31:50 <onen> shoragan: indeed. I face the exact same question here. my code for neighbour was beta (i.e. working, tested, but I had to understand some fields). do I store rxlev as given by the framework, or do I convert it...
Apr 19 15:31:51 <shoragan> need to bring this up with nick
Apr 19 15:32:13 <onen> shoragan: GetStatus() and so on already converts the value from modem, so this is not untainted neither ;-)
Apr 19 15:32:39 <shoragan> onen, as long as you have enough context, you can do any conversion layetr
Apr 19 15:32:48 <onen> shoragan: about device/model etc... yes indeed, don't you think this might be useful?
Apr 19 15:32:53 <shoragan> onen, i thought you used GetServingCellInfo
Apr 19 15:33:02 <shoragan> that is 'untainted'
Apr 19 15:33:23 <CIA-75> freesmartphone.org: 03mickey 07artwork * rbad59486e083 10/sounds/ (LICENSE djgriffin-groove.wav): add new ringtone
Apr 19 15:33:33 <shoragan> onen, when i looked at your code, i thought you were logging that already
Apr 19 15:33:48 <shoragan> maybe even framework version
Apr 19 15:34:13 <onen> shoragan: indeed. the idea was to write a logger which would work even if you do not have the optional serving/neighbours api. relying on standard GSM API (I know, some of them are opritonnal too)
Apr 19 15:34:30 <tmzt> mickeyl: would flac workor is this just testing?
Apr 19 15:34:41 <onen> shoragan: for neighbours, yes. GetNeighboursCellInformation
Apr 19 15:35:02 <shoragan> onen, i would switch to GetServingCellInfo
Apr 19 15:35:10 <shoragan> there you also get the TA
Apr 19 15:35:23 <shoragan> (which is only vaild when not idle)
Apr 19 15:35:42 <mickey|sun> tmzt: for non-wav we have gstreamer. if gstreamer supports flac, then we can use it
Apr 19 15:35:52 <mickey|sun> otherwise we would need to add a dedicated player for flac
Apr 19 15:36:11 <onen> shoragan: DocScrutinizer asks for TA, and indeed, I am thinking about switching because of it. But, imagine you get FSO on top of the eten m800. maybe we won't have access to this, but to regular GSM api yes
Apr 19 15:36:36 <shoragan> onen, yes, you would probably have to support both
Apr 19 15:36:46 <shoragan> and record in the report which one was used
Apr 19 15:37:03 <onen> shoragan: what I like with standard GSM API too, is that there are signals. this save some cpu cycles at every log
Apr 19 15:37:37 <shoragan> onen, i don't thing that the cpu usage is relevant here
Apr 19 15:37:39 <mrmoku> mickey|sun: hi, whom to talk to about opimd?
Apr 19 15:37:42 <tmzt> mickeyl: I misread AlsaPlayer as the program called alsaplayer, not aplay
Apr 19 15:37:52 <dos1> mrmoku: hey!
Apr 19 15:37:58 <mrmoku> dos1: hey :-)
Apr 19 15:38:07 <dos1> mrmoku: i commited few fixed to opimd few days ago
Apr 19 15:38:10 <dos1> about Messages
Apr 19 15:38:16 <mrmoku> dos1: yeah... saw it
Apr 19 15:38:17 <onen> shoragan: why? if logger runs hours, isn't it interesting to try to save computation time?
Apr 19 15:38:20 <dos1> did you do something with Messages, or only with Contacts?
Apr 19 15:38:24 <mickeyl> tmzt: if you want flac, we can add it, no problem
Apr 19 15:38:38 <mrmoku> dos1: care to implement Update() and Delete() for contacts? ;)
Apr 19 15:39:18 <onen> shoragan: I think all these points should be discussed, but put somewhere (wiki?).
Apr 19 15:39:25 <mrmoku> dos1: only Contacts so far
Apr 19 15:39:27 <tmzt> mickeyl: it's only because you have an uncompressed sound in a flash filesystem, seems out of place
Apr 19 15:39:33 <shoragan> onen, other parts of the FR are even less optimized, doing one less dbus roundtrip per 10 sec wont be measureable
Apr 19 15:39:39 <mrmoku> (apart from getting the contacts name when showing a message)
Apr 19 15:39:49 <onen> shoragan: :-D ok got your point
Apr 19 15:39:52 <mickeyl> tmzt: true, but this is for maximum speed only
Apr 19 15:40:01 <mickeyl> tmzt: most platforms will be ok with gstreamer
Apr 19 15:40:13 <mickeyl> only the openmoko devices are too slow for it
Apr 19 15:40:33 <tmzt> flac is just lossless compressed, decompression should be pretty fast/simple
Apr 19 15:40:45 <shoragan> onen, my point is, collect the data as "raw" as possible, as much data as possible, and all the context to make sense of that data
Apr 19 15:41:04 <tmzt> if a dedicated oss player would work there should be one
Apr 19 15:41:07 <onen> shoragan: another point is you guys from the framework have a lot of influence. maybe you could try to talk with cellhunter to see if this is only me who does not communicate well with him, or sth else.
Apr 19 15:41:34 <dos1> mrmoku: not now, girlfriend is here ;)
Apr 19 15:41:45 <mrmoku> dos1: send her away ;) :P
Apr 19 15:41:57 <onen> shoragan: would you like to be included in the email discussions between nick and I about the aspects of the log files?
Apr 19 15:42:34 <shoragan> onen, those discussions should be public anyway
Apr 19 15:42:48 <onen> shoragan: if the discussion (about server and db) goes public, which ML would you recommend?
Apr 19 15:43:58 <onen> shoragan: you are right. we do not use much of sourceforge tools for this, but phone, as it goes faster. will see with him to make this more public
Apr 19 15:44:13 <shoragan> smartphone-standards or your own one
Apr 19 15:44:40 <shoragan> but if it's not too much traffic and you want more comments use smartphone-standards
Apr 19 15:44:54 <mrmoku> mickeyl: did you take a look at the opimd code so far?
Apr 19 15:44:58 <onen> shoragan: for everything related to API on the phone, smartphone-standards makes sense to me
Apr 19 15:45:21 <shoragan> also convince him to make the server code publich, then other ppl can use your db dumps to try changes with live data
Apr 19 15:45:57 <mickeyl> mrmoku: just briefly a coupld of weeks ago
Apr 19 15:46:01 <onen> shoragan: as said earlier, I think the code is on sourceforge. but we will discuss this
Apr 19 15:46:18 <mrmoku> mickeyl: there is some important stuff missing... rest works nice :-)
Apr 19 15:46:29 <mrmoku> no updating or deleting of contacts
Apr 19 15:46:41 <mickeyl> right, guess we can add that
Apr 19 15:46:53 <mrmoku> :-)
Apr 19 15:46:59 <mrmoku> I rebased contacts in SHR on opimd
Apr 19 15:47:07 <mrmoku> works quite nice so far
Apr 19 15:48:29 <mrmoku> mickeyl: I took a closer look (wanted to add it)... will have to leave the python stuff for somebody else though :P
Apr 19 15:48:59 <onen> shoragan: I propose to start the email thread on my side.
Apr 19 15:49:16 <shoragan> sure, go ahead
Apr 19 15:49:39 <onen> shoragan: the neighbour code is almost ready, but it is fairly easy to change it if comments arrive
Apr 19 15:50:39 <onen> shoragan: ok. On your side, again if you have more luck than me with cellhunter about future collaboration... I would love to work together on one single code
Apr 19 15:50:51 <onen> shoragan: thanks for your comments
Apr 19 15:52:39 <Sharwin_F> mrmoku, I arrived to the conclusion that there's some gremlin doing weird things on fbreader package, the patch which makes it work on fr is not applied another time hehe
Apr 19 15:52:53 <Sharwin_F> mrmoku, hope you had a good holiday btw :)
Apr 19 15:53:41 <onen> shoragan: is debian.org email address fine?
Apr 19 15:54:27 <shoragan> sure
Apr 19 15:55:55 <mrmoku> Sharwin_F: hehe... gremlin... yeah might be :-(
Apr 19 15:55:59 <mrmoku> holliday was nice yeah
Apr 19 15:56:12 <mrmoku> brb
Apr 19 15:56:13 <mrmoku> exit
Apr 19 15:58:52 <onen> shoragan: ok, sent. wait for Nick answer (is not as available as I am ;-), not as geek :-P )
Apr 19 15:59:50 <onen> shoragan: by the way, as a debian developper, do you have pointers at how I could get openBmap into debian feed (pkg-fso?)? ask Joachim?
Apr 19 16:00:48 <shoragan> Joachim would be good
Apr 19 16:01:17 <onen> mrmoku: you were right, the N/A for GSM under openBmap logger was indeed a stupid bug from me
Apr 19 16:01:23 <onen> mrmoku: corrected in 0.2.1
Apr 19 16:02:34 <onen> shoragan: ok, thanks. I have been waiting to see if some merge could be done with cellhunter about logger, but as things have stalled, I have started hacking again, and plan to push it to the debian feed (already in FSO and SHR)
Apr 19 16:03:09 <shoragan> onen, i've looked at the opencellid dump, they don't even log if the cell was the serving one...
Apr 19 16:03:28 <shoragan> so cellhunter->opencellid will even loose data
Apr 19 16:08:03 <mrmoku> onen: what about uploading? site is down?
Apr 19 16:11:19 <von_fritz> dos1 check your mailbox
Apr 19 16:11:43 <dos1> von_fritz: i've seen, thanks :) will commit it soon
Apr 19 16:12:19 <onen> mrmoku: yes, shoragan pointed it to me. probably the personnal webpages where is it located is down for whatever reason
Apr 19 16:13:16 <onen> shoragan: opencellid (thomas tolk it in public the email thread) target quantity and coverage, not quality. we found measures with 2 or 3 digits after lat/lon, which means completely inacurate
Apr 19 16:13:26 <onen> s/tolk/told/
Apr 19 16:13:26 <bzzbot> onen meant: shoragan: opencellid (thomas told it in public the email thread) target quantity and coverage, not quality. we found measures with 2 or 3 digits after lat/lon, which means completely inacurate
Apr 19 16:14:16 <onen> shoragan: to my point of view, opencellid already contains quite some garbage
Apr 19 16:14:38 <shoragan> onen, yes, but any db of that size will contain some garbage
Apr 19 16:14:46 <shoragan> we need to cope with that
Apr 19 16:15:12 <shoragan> also the data will become outdated as the operators change their cells
Apr 19 16:15:27 <shoragan> both must be handled
Apr 19 16:17:12 <onen> shoragan: agreed. but it is easy to delete: inacurate GPS data, cell id which are out of norm, etc...
Apr 19 16:17:40 <onen> shoragan: I think he has no interest to do so, as his main argument his: opencellid is the biggest db
Apr 19 16:18:04 <shoragan> the easiest way is to discard any measurements which are not verified by others
Apr 19 16:18:36 <shoragan> for now, completely wrong cellids won't hurt
Apr 19 16:18:41 <onen> shoragan: we have already seen a cell id jumps from one lac to another. Nick had already much thinking about all of this
Apr 19 16:18:45 <shoragan> as the phone will never use them anyway
Apr 19 16:19:22 <shoragan> the cellid is only unique per LAC
Apr 19 16:19:44 <shoragan> or do you mean one "physical" cell at a given location changed it's lac?
Apr 19 16:20:03 <onen> shoragan: we are pretty sure this has changed. this is because of the way lac is used for managing numbers of people
Apr 19 16:20:17 <onen> shoragan: that is what we think, yes
Apr 19 16:20:40 <onen> shoragan: we have all the cells there, and suddently, a cell id had a different lac
Apr 19 16:21:19 <shoragan> interesting
Apr 19 16:21:48 <onen> shoragan: again, we should talk about this with Nick, he had much thinking about how to detect a lac/cell id does not exist any more, or cope with cell id changing lacs, etc...
Apr 19 16:22:20 <shoragan> from my understanding of GSM, the LAC identifies the MSC whicht cell is manange by, and that shouldn't change that often
Apr 19 16:23:37 <onen> shoragan: to my understanding (but here Nick is our specialist ;-) ), lac is only an abstraction level to minimise data exchange in the network. as lonng as you stay in a lac, some data only goes up to the lac, but not higher in the network infrastructure
Apr 19 16:24:12 <onen> shoragan: so, if demography changes, it could make sense to move one border cell id, to another lac
Apr 19 16:24:19 <onen> shoragan: that is our hypothesis
Apr 19 16:24:22 <tmzt> but does the location usually change for a cellid?
Apr 19 16:24:36 <onen> tmzt: what do you mean?
Apr 19 16:24:41 <tmzt> gps
Apr 19 16:24:44 <alphaone> Yes, that could happen
Apr 19 16:24:45 <tmzt> lat/lon
Apr 19 16:25:01 <alphaone> In reality it sometimes happens I was told
Apr 19 16:25:13 <shoragan> onen, but lac is not only an abstraction
Apr 19 16:25:29 <onen> alphaone: do you answer my story about cell id jumping lac, or to the question of tmzt?
Apr 19 16:25:36 <shoragan> each cell (BSC) is connected to one MSC (which is identified by the LAC)
Apr 19 16:25:42 <alphaone> i.e. in case of a sports event there will be additional cells in the area and other cells will be adjusted accordingly
Apr 19 16:25:47 <shoragan> so this connection must have changed
Apr 19 16:26:03 <tmzt> and they reuse cellids?
Apr 19 16:26:07 <onen> shoragan: ok, ok, you have reached the limit of my GSM knowledge! ;-) Nick knows better
Apr 19 16:27:13 <onen> shoragan: tmzt: alphaone: so Nick had some thoughts about how to detect a cell id jump, and keep using the data we have so far about it, despite the new lac
Apr 19 16:35:48 <CIA-75> freesmartphone.org: 03mickey 07framework * r08aa67ed29fb 10/framework/subsystems/ogsmd/modems/ti_calypso/unsolicited.py: ogsmd: [TI CALYPSO] report call mode (voice, data, ...) in org.freesmartphone.GSM.CallStatus
Apr 19 16:44:34 <schasch> good evening
Apr 19 16:45:52 <Zorkman> evening
Apr 19 16:50:17 <bumbl> good morning
Apr 19 16:50:22 <bumbl> ;) ugt
Apr 19 16:51:10 <Zorkman> hehe
Apr 19 16:51:27 <Zorkman> btw: small qi question: are there plans to support multi-boot with qi?
Apr 19 16:51:44 <bumbl> multi-boot is supported
Apr 19 16:51:48 <bumbl> press aux
Apr 19 16:51:54 <Zorkman> oh
Apr 19 16:52:00 <bumbl> to rotate kernels
Apr 19 16:52:06 <mickeyl> anyone ever used data calls? how does the callee find out the proper datarate? 
Apr 19 16:52:17 <mickeyl> or is everyone and his brother just using 9600 ?
Apr 19 16:52:41 <bumbl> datacalls
Apr 19 16:52:46 <bumbl> sounds slow
Apr 19 16:52:56 <tmzt> what csd/hscsd?
Apr 19 16:53:01 <mickeyl> csd
Apr 19 16:53:32 <mickeyl> i don't see any signalling mechanism nor commands to find out the data rate 
Apr 19 16:53:40 <mickeyl> [on the callee side]
Apr 19 16:53:42 <beniwtv> mickeyl: 9600 is the maximum for "data calls" on many phones, otherwise use GPRS
Apr 19 16:53:51 <tmzt> you don't get that from CONNECT?
Apr 19 16:54:00 <mickeyl> no, only the caller get it with CONNECT
Apr 19 16:54:03 <mickeyl> the callee doesn't
Apr 19 16:54:51 * mickeyl tries calling vice versa to be sure
Apr 19 16:55:01 <tmzt> no unsol with RING?
Apr 19 16:55:54 <mickeyl> nope
Apr 19 16:56:05 <mickeyl> of course it gets the CRING: REL ASYNC
Apr 19 16:56:16 <mickeyl> but like i said, no data rate indication 
Apr 19 16:56:17 <mickeyl> fun :D
Apr 19 16:56:23 <mickeyl> guess that means fixed forever
Apr 19 16:56:52 <tmzt> difference between csd/hscsd calling?
Apr 19 16:56:57 <alphaone> Doesn't the modem take care of handling out data rates by itself?
Apr 19 16:57:01 <mickeyl> no idea, never did the latter one
Apr 19 16:57:09 <tmzt> or does the network use whats available
Apr 19 16:57:33 <mickeyl> alphaone: the thing is... you can set the data rate, but not read it :)
Apr 19 16:57:36 <tmzt> but isn't csd fixed to tdm channel, bits in the frames?
Apr 19 16:58:32 <tmzt> how do you set it?
Apr 19 16:58:38 <alphaone> mickeyl: But if a connection is established with this setting you'll know that this is the one?
Apr 19 16:58:50 <tmzt> on one end
Apr 19 16:59:01 <mickeyl> you set it with the bearer service command
Apr 19 16:59:01 <alphaone> So just transmit the data rate over the connection once established :-)
Apr 19 16:59:15 <mickeyl> well
Apr 19 16:59:22 <mickeyl> that would require that you know it
Apr 19 16:59:27 <mickeyl> otherwise you get garbage :D
Apr 19 16:59:31 <mickeyl> ah well, you can SMS it :D
Apr 19 16:59:37 <alphaone> really?
Apr 19 17:00:07 <mickeyl> hmm
Apr 19 17:00:08 <mickeyl> let me try
Apr 19 17:00:15 <mickeyl> i set to something bogus on one side now
Apr 19 17:00:17 <alphaone> So you can set up a call where one end thinks it's talking at 9600 and the other one thinks it's talking at 2400 baud
Apr 19 17:00:23 <mickeyl> trying exactly that
Apr 19 17:00:27 <alphaone> That would be strange
Apr 19 17:00:36 <alphaone> I would assume either
Apr 19 17:00:43 <alphaone> 1. The connection fails
Apr 19 17:00:59 <alphaone> or 2. the connection is made with min(a, b) baud
Apr 19 17:01:40 <alphaone> mickeyl: Don't spend all your money on CSD calls ;-)
Apr 19 17:02:35 <shoragan> playya__, are you here?
Apr 19 17:03:15 <mickeyl> aaaah
Apr 19 17:03:27 <mickeyl> (money) well, i promised it to that swiss guy to get csd going
Apr 19 17:03:28 <shoragan> http://trac.freesmartphone.org/ticket/407
Apr 19 17:03:32 <mickeyl> ok, i got it wrong
Apr 19 17:04:06 <mickeyl> with the bearer service you can only set it for outgoing connections
Apr 19 17:04:11 <shoragan> the connection speed is only relevant for real serial connections anyway
Apr 19 17:04:13 <mickeyl> and only the callee gets the data rate on connect
Apr 19 17:04:26 <mickeyl> so it's all good
Apr 19 17:04:33 <mickeyl> because the calller knows how he calls
Apr 19 17:04:34 <DocScrutinizer> mrmoku: HIII!
Apr 19 17:04:36 <mickeyl> and the callee gets it
Apr 19 17:04:48 <tmzt> ATA
Apr 19 17:04:55 <tmzt> CONNECT br
Apr 19 17:04:56 <tmzt> ?
Apr 19 17:05:02 <mickeyl> no i get more here:
Apr 19 17:05:04 <alphaone> yay
Apr 19 17:05:09 <mickeyl> ata
Apr 19 17:05:10 <mickeyl> +CR: REL ASYNC
Apr 19 17:05:10 <mickeyl> +ILRR: 115200
Apr 19 17:05:10 <mickeyl> CONNECT 9600/RLP
Apr 19 17:05:23 <tmzt> ok
Apr 19 17:05:26 <alphaone> ~praise the AT commands as they are always straight forward
Apr 19 17:05:26 <bzzbot> okay, alphaone
Apr 19 17:05:27 <mickeyl> so this is all fine
Apr 19 17:05:30 <mickeyl> hehe
Apr 19 17:05:46 <mickeyl> fun enough, the calypso can't call with something else than 9600
Apr 19 17:05:47 <DocScrutinizer> heh, what U guys are doing there? o.O :)
Apr 19 17:05:54 <mickeyl> i always get NO CARRIER on other bearer types
Apr 19 17:05:56 <mickeyl> :)
Apr 19 17:06:03 <alphaone> DocScrutinizer: supporting cryptophone :-)
Apr 19 17:06:09 <DocScrutinizer> hehe
Apr 19 17:06:13 <tmzt> all othere bearers?
Apr 19 17:06:14 <mickeyl> wasting money with CSD
Apr 19 17:06:23 <alphaone> As I said :-)
Apr 19 17:06:24 <mickeyl> tmzt: oh well, didn't try _all_ others ;)
Apr 19 17:06:30 <DocScrutinizer> well CSD isbn't that bad
Apr 19 17:06:42 <DocScrutinizer> coool anyway
Apr 19 17:06:44 <mickeyl> the calypso can't do anything faster anyways, so i just tried 4600 and 2400
Apr 19 17:06:49 <mickeyl> 4800, that is
Apr 19 17:07:14 <tmzt> no hscsd?
Apr 19 17:07:26 <mickeyl> doubtful
Apr 19 17:07:33 <DocScrutinizer> hmmpf
Apr 19 17:07:33 <tmzt> and I assume gprs/edge aren't point to point?
Apr 19 17:07:38 <mickeyl> correct
Apr 19 17:07:50 <mickeyl> data calls are the only way to call p2p
Apr 19 17:08:05 <mickeyl> you need remote server assistance for anything else
Apr 19 17:08:14 <mickeyl> this defeats the point of the exercise :)
Apr 19 17:08:27 <DocScrutinizer> hehe
Apr 19 17:08:38 <DocScrutinizer> not exactly though
Apr 19 17:08:39 <shoragan> mickeyl, please look at http://trac.freesmartphone.org/ticket/407
Apr 19 17:08:41 <tmzt> voip through csd
Apr 19 17:08:44 <tmzt> magic
Apr 19 17:09:02 <DocScrutinizer> no magic
Apr 19 17:09:03 <tmzt> not voip but digital codecs
Apr 19 17:09:05 <mickeyl> shoragan: i can do, although this is playya__'s baby
Apr 19 17:09:12 <mickeyl> playya__: ?
Apr 19 17:09:32 <shoragan> mickeyl, it currently makes more problems that it solved
Apr 19 17:09:34 <mickeyl> shoragan: btw., why did you rewrite idlenotifier to waste energy? we're polling now :/
Apr 19 17:09:52 <mickeyl> shoragan: you can disable it for now
Apr 19 17:09:54 <onen> shoragan: mrmoku: it seems openBmap website is up again
Apr 19 17:09:59 <mickeyl> shoragan: at least the autostart
Apr 19 17:10:01 <alphaone> mickeyl: there were races
Apr 19 17:10:14 <onen> mrmoku: Nick told me you logged quite a lot, thanks for this!
Apr 19 17:10:30 <onen> bbl
Apr 19 17:10:35 <shoragan> mickeyl, idlenotifier was more or less broken since you added display/cpu handling
Apr 19 17:10:42 <alphaone> request CPU, request: Display, release CPU and display would dim
Apr 19 17:10:44 * DocScrutinizer wonders if calypso can/could learn HSCSD
Apr 19 17:10:48 <mrmoku> DocScrutinizer: hey... how's life?
Apr 19 17:10:50 <shoragan> as soon as one was released, it went back to default
Apr 19 17:11:07 <mrmoku> DocScrutinizer: any progress on alsa? :P
Apr 19 17:11:12 <DocScrutinizer> mrmoku: changing, always changing ;-)
Apr 19 17:11:19 <mickeyl> and there was no other way to fix this but go to a polling scheme?
Apr 19 17:11:27 <shoragan> and it didn't handle cases where you couldn't read for the input node and so killed the io watch
Apr 19 17:11:27 <alphaone> That I don't know
Apr 19 17:11:40 <DocScrutinizer> was wondering when you're beack so I'm urged to show off some progress
Apr 19 17:11:51 * mrmoku --> good night story
Apr 19 17:11:58 <mrmoku> DocScrutinizer: you still have 15 minutes ;)
Apr 19 17:12:04 <DocScrutinizer> hehe
Apr 19 17:13:01 <tmzt> mickeyl: you could do what android does and put it all in the kernel :)
Apr 19 17:13:21 * mickeyl pretends he didn't hear this outrageous suggestion
Apr 19 17:13:35 <DocScrutinizer> mickeyl: alphaone: yo tried to change from a standard voicecall to CSD on the fly by issuing ATO / ATA ?
Apr 19 17:13:44 <shoragan> also i wanted to switch between io_watches and polling
Apr 19 17:14:07 <shoragan> switch to polling when input arrived, switch back do io_watch when idle
Apr 19 17:14:22 <shoragan> so we don't wake up python for every touch screen event
Apr 19 17:14:28 <alphaone> DocScrutinizer: Never tried anything with CSD
Apr 19 17:14:30 <shoragan> makes scrolling smoother
Apr 19 17:15:06 <alphaone> Cool
Apr 19 17:15:20 <alphaone> That would even save battery
Apr 19 17:16:00 <shoragan> before it was reading ~50 every time
Apr 19 17:16:40 <mickeyl> DocScrutinizer: i don't see how the TE can specify the calltype. you would need to call with VOICE/REL ASYNC instead of VOICE then. I can only see how to switch to REL ASYNC, not to any of the alternate types.
Apr 19 17:16:53 <tmzt> what is python doing with touchscreen events?
Apr 19 17:17:40 <shoragan> tmzt, watching idle/busy state
Apr 19 17:18:06 <tmzt> but every event is passed through?
Apr 19 17:18:42 <alphaone> shoragan: This could speed up a lot of things that happen when you press the touchscreen
Apr 19 17:19:15 <shoragan> tmzt, currently yes
Apr 19 17:19:28 <tmzt> is there a pen gpio?
Apr 19 17:19:35 <shoragan> maybe you cna filter them
Apr 19 17:19:39 <mickeyl> DocScrutinizer: calypso doesn't seem to honor the +CMOD setting
Apr 19 17:19:49 <mickeyl> at least here
Apr 19 17:19:55 <mickeyl> didn't try extensively though
Apr 19 17:24:14 <CIA-75> freesmartphone.org: 03mickey 07framework * r882ca6eab68a 10/ (2 files in 2 dirs): ogsmd: do not bail out if call mode is != VOICE
Apr 19 17:31:42 <plhardy> hi all
Apr 19 17:32:03 <plhardy> what is status of wifi with latest testing ?
Apr 19 17:32:15 <plhardy> i didn't manage to get it working
Apr 19 17:34:51 <bumbl>  mrmoku: welcome back
Apr 19 17:34:58 <bumbl> how were the holidays?
Apr 19 17:43:47 <dos1> plhardy: did you turned on wifi in shr settings?
Apr 19 17:43:50 <plhardy> i can scan network, but i don't manage to get any valid signalwhen setting essid or whatever 
Apr 19 17:44:20 <dos1> plhardy: you are doing it wrongly or you have some kernel issue
Apr 19 17:44:21 <Sharwin_F> dos1, looks like tangogps icon doesn't appear on shr-testing, could you add a right category on the desktop file please? :)
Apr 19 17:44:26 <dos1> s/issue/bug/ ;p
Apr 19 17:45:00 <dos1> Sharwin_F: i think we should tweak applications.menu, but not in the way in which FSO did
Apr 19 17:45:02 <plhardy> dos1: yes i turned it on and when i try to use mofi it hang at some point
Apr 19 17:45:15 <dos1> we should add "Application" to rule with "Applications"
Apr 19 17:45:20 <plhardy> after mofi problem even a iwconfig essid XXX fails
Apr 19 17:46:08 <plhardy> dos1: have an idea how to set it up manually to see whether it is a kernel issue ?
Apr 19 17:46:38 <plhardy> ode:Managed  Bit Rate=1 Mb/s   Tx-Power=0 dBm   Sensitivity=0/3
Apr 19 17:46:55 <plhardy> i would like to activate the Tx-Power ...
Apr 19 17:47:18 <plhardy> when iwconfig fails i remove ar6000 and reprobe it
Apr 19 17:47:52 <Sharwin_F> dos1, /etc/xdg/menus/applications.menu looks quite empty
Apr 19 17:49:05 <dos1> Sharwin_F: you have menu-freesmartphone installed, or e-wm-menu?
Apr 19 17:49:07 <plhardy> i have traces in dmesg : AR6000 disconnected
Apr 19 17:49:50 <plhardy> but scan works...
Apr 19 17:49:57 <dos1> plhardy: we can have similar bugs
Apr 19 17:50:13 <dos1> plhardy: can you test if wifi works on 2.6.24 for you? or test with other accesspoint?
Apr 19 17:50:34 <Sharwin_F> dos1, it works for me, it happens when installing shr-testing from yesterday
Apr 19 17:52:22 <Sharwin_F> I'm using unstable atm
Apr 19 17:52:30 <mrmoku> bumbl: fine thanks
Apr 19 17:52:34 <mrmoku> DocScrutinizer: and?
Apr 19 17:52:43 <plhardy> dos1: would a opkg install kernel2.6.24 or something like that work ?
Apr 19 17:54:46 <bumbl> mrmoku: opimd ;)
Apr 19 17:55:00 <mrmoku> bumbl: yep... getting closer :D
Apr 19 17:55:09 <bumbl> excellent
Apr 19 17:55:47 <mrmoku> need to get someone to work on the fso side on it now...
Apr 19 17:55:50 <mrmoku> dos1: ping :-)
Apr 19 17:56:08 <dos1> mrmoku: pong :>
Apr 19 17:56:09 <max_posedon> mickey|dinner, Hi! Could you help me with your python-2.6.1 cross-compilation patches? (trying port them to gentoo) have problems with some strange asm instructions.
Apr 19 17:56:16 <max_posedon> (when you come back)
Apr 19 17:56:25 <dos1> my girffriend doesn't like you, mrmoku ;D
Apr 19 17:56:40 <dos1> she read your message about her ;)
Apr 19 17:56:41 <mrmoku> dos1: hope you appreciate that ;)
Apr 19 17:56:48 <mrmoku> (my wife does :P)
Apr 19 17:57:20 <coney> heh
Apr 19 17:58:24 <mrmoku> dos1: what would you think about hacking a bit on opimd?
Apr 19 17:58:46 <mrmoku> (if your girlfriend is gone of course)
Apr 19 17:58:48 <sylar91> mrmoku: isn't it easily possible to get a temporany fix to see sim contacts' names and no numbers in the sms app? (before to get opimd integrated)
Apr 19 17:59:53 <dos1> sylar91: i think it's possible. mrmoku, i think we should start from that ;)
Apr 19 18:00:07 <mrmoku> sylar91: well... I hacked a lot on the contacts and messages apps...
Apr 19 18:00:23 <mrmoku> and yeah... I would know how to do it now :-)
Apr 19 18:00:25 <dos1> mrmoku: i agree. i would like to do it ;)
Apr 19 18:00:33 <sylar91> because it is the first issue that a lot of people notices trying shr
Apr 19 18:00:56 <mrmoku> on the other hand I have almost working contacts based on opimd
Apr 19 18:01:04 <mrmoku> (including showing the name in messages)
Apr 19 18:01:13 <sylar91> wow
Apr 19 18:01:48 <dos1> mrmoku: can you commit showing name in messages now? it shouldn't brake anything i think
Apr 19 18:02:18 <mrmoku> dos1: well... it get's names from opimd... so it would not even compile with libframeworkd-glib master branch ;)
Apr 19 18:02:36 <sylar91> doh :(
Apr 19 18:02:52 <dos1> mrmoku: so add opimd stuff to libframeworkd-glib master branch, as you tested it and it works
Apr 19 18:03:06 <dos1> allow anyone to use it with lfg ;p
Apr 19 18:03:06 <mrmoku> but I can sort it out... add an opimd branch to our apps and do a gsmd version for the names
Apr 19 18:03:19 <mrmoku> dos1: or that, yeah
Apr 19 18:04:45 <mrmoku> dos1: how is the state of shr-unstable? I read Ainulindale's blog about unstable-->testing 
Apr 19 18:04:54 <mrmoku> is unstable ready to get broken? :P
Apr 19 18:05:00 <sylar91> lol
Apr 19 18:05:25 * mwester is also working hard to break unstable!
Apr 19 18:05:41 <mrmoku> mwester: I always apreciate any help :-)
Apr 19 18:05:44 <mrmoku> +p
Apr 19 18:05:52 <Sharwin_F> don't worry for me, I've already upgraded and works, just remember me not to upgrade more! :P
Apr 19 18:06:12 <mwester> Hey, is anyone going to clean up the horrid mess that the /usr/share/applications/*.desktop files have become?
Apr 19 18:06:18 <mwester> Who's in charge of that
Apr 19 18:06:19 <mwester> ?
Apr 19 18:06:39 <mrmoku> mwester: you mean the categories?
Apr 19 18:06:46 <mwester> That's one of the issues.
Apr 19 18:07:15 <mwester> Some of them also have double "Exec" lines -- which one is to be honored???
Apr 19 18:07:21 <Wiedi> mwester, just read your mail to the list about g_ether mac addresses. i'd like to have it work with u-boot, so i see that to read the mac i can mount mtdblock5. is there a problem with always mounting that partition to a known location?
Apr 19 18:07:32 <mwester> And do we have an artist to make more of those nice-looking icons?
Apr 19 18:08:09 <mrmoku> mwester: I guess most .desktop come from apps upstream... some from SHR
Apr 19 18:08:19 <Wiedi> I'd path your script to read the address from there then
Apr 19 18:08:27 <mrmoku> and all get categories added somewhere in the rootfs script :-)
Apr 19 18:08:47 <mwester> Wiedi:  no problem, but you shouldn't need to -- it is a modifiable partition so if you forget to mount it read-only, it is possible you can delete that information, and it would be very very difficult to get it back.  I would recommend NOT to mount it.
Apr 19 18:08:55 <dos1> mrmoku: no, i removed that ;x
Apr 19 18:09:07 <dos1> vala-terminal has Exec added in rootfs generation i think
Apr 19 18:09:11 <mrmoku> dos1: ahh :-)
Apr 19 18:09:26 <Wiedi> ok, so better mount it on first boot and make a copy to the rootfs? :)
Apr 19 18:09:28 <dos1> mrmoku: we should write some sed script to change Application; to Applications;
Apr 19 18:09:32 <dos1> mrmoku: can you do that?
Apr 19 18:09:34 <Wiedi> (und umount after that)
Apr 19 18:09:46 <mrmoku> dos1: for rootfs?
Apr 19 18:10:05 <dos1> mrmoku: yep. that echo with category was causing all shr-settings icons displaying on desktop ;)
Apr 19 18:10:09 <mwester> Wiedi:  I would prefer people upgrade to Qi, or add it once to the u-boot env.  THe mount on first-boot is something I considered, but rejected because I would prefer that no distros ever touch that partition, lest something go horribly wrong.
Apr 19 18:10:51 <mrmoku> dos1: well... we should not do that in rootfs... try to fix all apps instead
Apr 19 18:11:02 <mwester> Wiedi:  I would actually implement a solution on first-boot that would cat the contents of that partition to some code that would read the ext2 structure to extract the data, just to avoid mounting that partition.
Apr 19 18:13:08 <mwester> Wiedi:  something like dd to a file, then do a loopback mount of the file, so that the original content would never be altered.  Not hard, just difficult to do in the g_ether.sh script, because that script actually runs before udev runs, so we have no devices yet.  Ooops!
Apr 19 18:13:09 <Wiedi> cat on first boot sounds good, i actually modified my u-boot env, but think it would be great to just work ;D
Apr 19 18:13:19 <mwester> I agree.
Apr 19 18:13:23 <Wiedi> oh
Apr 19 18:13:40 <mwester> It would be good to have a distro that would run completely correctly with no required u-boot changes.
Apr 19 18:14:18 <mwester> If enough people enquire, I'll take another look (but right now I'm workign on some other issues. :)
Apr 19 18:15:12 <Wiedi> i can look into it later, just have to eat something 
Apr 19 18:17:39 <bumbl> hmm how do you explain average joe the value of the freerunner?
Apr 19 18:18:24 <Zorkman> "very cool if you want to spend a lot of time on your phone, ticker with it and use it as a programmable vibrator" ?
Apr 19 18:18:35 <Zorkman> *tinker
Apr 19 18:18:35 <mwester> bumble comes, and bumbl goes...
Apr 19 18:19:17 <bumbl> hmm
Apr 19 18:19:32 <bumbl> Zorkman: well average joe would not understand that i think
Apr 19 18:20:27 <bumbl> when i was asked it i couldn't find any arguments except "it is special" and "it has gps and wlan and a touchscreen"
Apr 19 18:21:43 <bumbl> ah and "it is so massive you could easily kill someone with it - no need to carry a gun"
Apr 19 18:24:26 <mrmoku> onen: just finished uploading 2022 log files...
Apr 19 18:25:31 <bumbl> wow
Apr 19 18:25:35 <bumbl> hmm
Apr 19 18:25:42 * bumbl has some logfiles too
Apr 19 18:25:58 <bumbl> but i hate signing up for such things
Apr 19 18:26:53 <mrmoku> bumbl: yeah... understand that
Apr 19 18:27:16 <bumbl> onen: how about creating an anonymous account which makes all the data uploaded to it public domain
Apr 19 18:27:26 <bumbl> -> no license issues
Apr 19 18:28:14 <onen> mrmoku: yeah, Nick told me that someone uploaded a lot. I knew it was you. Too bad the neighbour cell code is not yet activated, this would have been about 4 times more cells ;-)
Apr 19 18:29:22 <onen> bumbl: I don't remember if this was with you I talked about this. But, you have to give attribution for the data to the contributors (creative commons). I don't know if this is necessary for public domain
Apr 19 18:29:23 <mrmoku> onen: btw.... what happens when you don't properly end logging? (aka FR freezes)?
Apr 19 18:30:20 <onen> bumbl: so I don't know if uploading using one specific account exposed as "this is for public domain" would do the trick. I mean, legally.
Apr 19 18:30:29 <bumbl> onen: yes it was me
Apr 19 18:30:55 <onen> bumbl: but otherwise I have nothing against it. openstreetmap contributors for some of them, publish the data under dual license
Apr 19 18:31:57 <Zorkman> onen: why is neiggbour cell not yet activated?
Apr 19 18:32:19 <onen> mrmoku: the worst case would be: FR freezes while writing a log file. This would lead to upload of truncated log file to the server. And I hope the code of Nick is strong enough to support that ;-)
Apr 19 18:32:56 <onen> mrmoku: otherwise, out of during write of a log file, nothing wrong happens. logs are stored in memory, until written at once on the phone
Apr 19 18:33:29 <onen> mrmoku: so if app freezes, well... you loose the logs in memory (so far up to three, but next version will be much, much,..., much more :-( )
Apr 19 18:33:54 <onen> Zorkman: hello. thanks for your support on ML today ;-)
Apr 19 18:34:24 <mrmoku> onen: well... shit... lost a lot of cells then ;)
Apr 19 18:35:09 <onen> Zorkman: 1. I wanted to clarify meaning of some fields. 2. wanted to be sure, the neighbours have the same MCC MNC at the serving, to prevent mixing at borders 3. I wanted to see if sth would come out of the thread started by Stefan about projects collaboration, (merge?)
Apr 19 18:35:32 <onen> Zorkman: now that the discussion has stalled, and nothing came out of it, I have started again hacking on my logger
Apr 19 18:36:10 <sylar91> how is it possible to set the fr's usb to mass_storage mode?
Apr 19 18:36:21 <onen> Zorkman: I plan to re-activate the neighbour code beginning of the week, and this may be enough to justify a new release
Apr 19 18:38:02 <onen> mrmoku: lost a lot? currently you cannot. only lose three measures. or you modified the amount of logs per file in config file ;-)
Apr 19 18:38:31 <mrmoku> onen: ahh... it regularily writes out logs? that would be fine then :-)
Apr 19 18:38:55 <onen> bumbl: I had your suggestion to my Todo list, this is not much, but then I won't forget it (which means you will have right to complain that I did not do it :-P )
Apr 19 18:39:17 <onen> mrmoku: yes, so far, standard config is every 3 successful measure, write a file
Apr 19 18:40:18 <onen> mrmoku: 3 measures, is about 1kB, planned standard size will be 20 kB (but neighbour cells will make every measure about 4times bigger). do your maths ;-)
Apr 19 18:40:45 <mrmoku> onen: will check the map when it got generated :P
Apr 19 18:41:29 <onen> mrmoku: Map status (last update 2009-04-19 18:37:41)
Apr 19 18:41:57 <mrmoku> onen: does it get updated once a day?
Apr 19 18:42:02 <plhardy> dos1: i don't better wifi connectivty with 2.6.24 kernel of om2008.12 for the moement
Apr 19 18:42:11 * mrmoku uploaded after that
Apr 19 18:42:37 <onen> mrmoku: Nick updates it when he sees uploads. But he is working on triggering update automatically. I cannot tell how this will work then.
Apr 19 18:43:01 <mrmoku> ahh, ok. ic. thanks
Apr 19 18:45:24 <bumbl> onen: thanks
Apr 19 18:45:37 <onen> mrmoku: as stated earlier you were right, there was a but in 0.2.0, (N/A for GSM where obviously there was coverage), and this has been corrected in 0.2.1
Apr 19 18:46:19 <onen> bumbl: no pb. (I add your suggestion... and not "I had your suggestion", don't complain right now :-P )
Apr 19 18:47:13 <onen> mrmoku: I suggested to Nick to send an email to people when their files have been processed. sth similar to oepnstreetmap
Apr 19 18:47:30 <onen> mrmoku: but I think with the time he has, this is not on top of his todo list
Apr 19 18:48:36 <Zorkman> onen: i would also agree that enabling neigbours justifies a new release
Apr 19 18:49:39 <Zorkman> mrmoku: just a thought, i don't find it very nescessary, but it's still kinda strange that in the DATE/time settings one can not change or view the date
Apr 19 18:49:51 <Zorkman> sorry, above was meant for dos1
Apr 19 18:51:25 <onen> Zorkman: I think I will target this schedule: test neighbours, then release. rest (timing advance, etc...) will be then for release afterwards
Apr 19 18:51:32 <bumbl> mickey|dinner: ping
Apr 19 18:51:56 <onen> bumbl: mrmoku: Zorkman: thanks for your comments. bbl
Apr 19 18:54:21 <tmzt>     
Apr 19 18:56:24 <Zorkman> is it smart to do an opkg upgrade on testing?
Apr 19 18:56:32 <Zorkman> seems like a lot of kernel modules...
Apr 19 18:59:17 <bumbl> you get a random kernel according to mwester 
Apr 19 19:01:39 <Zorkman> and do i want a random kernel bumbl? :)
Apr 19 19:05:46 <bumbl> Zorkman: well i don't
Apr 19 19:05:51 <bumbl> ~seen everslick
Apr 19 19:05:52 <bzzbot> bumbl: i haven't seen 'everslick'
Apr 19 19:06:20 <Sharwin_F> lol
Apr 19 19:10:39 <PaulFertser> What's up with Sebastian? He didn't give answers to the most important cellid database-related questions, just some not important words :-/
Apr 19 19:11:31 <playya> shoragan, I'm back
Apr 19 19:13:16 <shoragan> http://trac.freesmartphone.org/ticket/407
Apr 19 19:13:17 <playya> shoragan, which version of vala do you use?
Apr 19 19:13:29 <shoragan> could you please check whats wronge there?
Apr 19 19:13:36 <playya> yes
Apr 19 19:13:40 <shoragan> the default one build by fso/ms5.5
Apr 19 19:13:53 <playya> ok thats 0.6.0
Apr 19 19:13:55 <shoragan> i don't have time tonite
Apr 19 19:14:04 <shoragan> sry
Apr 19 19:14:10 <playya> i don't have a OE setup
Apr 19 19:15:28 <Sharwin_F> http://scap.linuxtogo.org/files/071114f77f2687065a65f9d8a1f76bee.png, is this a phonelog written using efl or just a gtk efl alike theme? In case of being a theme, would be great to lookf for it and add it
Apr 19 19:33:58 <sylar91> Sharwin_F: it is just te b&w gtk theme (look @ the ML)
Apr 19 19:34:29 <Sharwin_F> sylar91, which one?
Apr 19 19:34:41 <Sharwin_F> shr? where can I read it?
Apr 19 19:35:39 <sylar91> yes, under shr section
Apr 19 19:35:51 <dos1> Sharwin_F: i uploaded that screen, i want to package that theme in shr
Apr 19 19:36:17 <Sharwin_F> dos1, good :)
Apr 19 19:36:24 <sylar91> dos1: it is the b&w E gtk theme, right?
Apr 19 19:37:24 <sylar91> I'm using it too :) ( http://scap.linuxtogo.org/files/a1a9eff4dd91aa41316dec83dd33e6ee.png )
Apr 19 19:40:16 <mrmoku> sylar91: hehe... when I passed by verona some hour ago it was not yet raining ;)
Apr 19 19:40:24 <dos1> sylar91: yep ;)
Apr 19 19:41:46 <bumbl> Sharwin_F: it will be default gtk theme soon afaik
Apr 19 19:42:07 <bumbl> hmm too late
Apr 19 19:42:30 <Sharwin_F> too late?
Apr 19 19:43:33 <bumbl> Sharwin_F: your question was answered minutes ago
Apr 19 19:43:42 <bumbl> i should have read all of the backlog
Apr 19 19:43:45 <bumbl> before posting
Apr 19 19:43:47 <Ainulindale> mrmoku: hey o/
Apr 19 19:43:48 <Sharwin_F> hehe ok
Apr 19 19:46:37 <mrmoku> Ainulindale: hey :-) 
Apr 19 19:46:49 <mrmoku> Ainulindale: got your internet I guess :P
Apr 19 19:46:58 <Ainulindale> Nope
Apr 19 19:47:02 <Ainulindale> Hijacking wifi these days
Apr 19 19:47:08 <mrmoku> :-)
Apr 19 19:47:14 <Ainulindale> Well, see the mess I did when you weren't there?
Apr 19 19:47:23 <mwester> He's back!
Apr 19 19:47:23 <bumbl> Ainulindale: tut tut
Apr 19 19:47:29 <mrmoku> Ainulindale: yep... still busy working through it ;)
Apr 19 19:47:52 <Ainulindale> mrmoku: well nothing truly special anyway
Apr 19 19:47:59 <Ainulindale> Mostly organizing stuff, cleaning the tickets & such
Apr 19 19:48:18 <mrmoku> well... and swapping around branches :-)
Apr 19 19:48:27 <Ainulindale> well branches are equal now
Apr 19 19:48:53 <mwester> except the ${AUTOREV} stuff needs to be re-visitied.
Apr 19 19:49:00 <Ainulindale> Why is that?
Apr 19 19:49:00 <mwester> er, re-visited even
Apr 19 19:49:10 <mwester> I had to adjust some 
Apr 19 19:49:15 <Ainulindale> Well, why?
Apr 19 19:49:17 <mwester> I don't know if I did it right.
Apr 19 19:49:22 <mrmoku> did not check OE yet... did fso/ms5.5 switch to recipes?
Apr 19 19:49:26 <Ainulindale> mrmoku: yep
Apr 19 19:50:23 <mwester> testing wouldn't build, the stuff in the shr git repo was failing the install step (no target to make install).  It was stuck one rev behind your last change... 
Apr 19 19:50:43 <Ainulindale> Well that may mean that I borked my rev change :-)
Apr 19 19:51:02 <mwester> That's why I say someone who know needs to look at it.
Apr 19 19:51:09 <Zorkman> accelerometers are disabled in shr testing???
Apr 19 19:51:10 <mwester> I just made it build, I don't know if its right.
Apr 19 19:51:17 <Zorkman> in previous testing games like acceleroids worked perfectly
Apr 19 19:51:32 <mwester> Zorkman:  shouldn't be -- but the kernel folks changed the API
Apr 19 19:51:44 <mwester> They change APIs like most people change underwear.
Apr 19 19:51:53 <Zorkman> bah
Apr 19 19:52:22 <Zorkman> will it be fixed in shr-testing?
Apr 19 19:52:39 <mwester> The upstream apps need to update their code
Apr 19 19:56:31 <PaulFertser> Zorkman: for the accel api change there was a perfect reason (really!) and everybody was warned in advance (like a month or more).
Apr 19 19:56:38 <dos1> Zorkman: so acceleroids and other apps need to be updated
Apr 19 19:59:40 * PaulFertser wonders why so many userspace apps suffer so much from kernel api changes. After all, they have time to play acceleroids, why not spend 15min updating it?!
Apr 19 19:59:59 <PaulFertser> (they==acceleroids users)
Apr 19 20:00:39 <Zorkman> because i can't code my own fingers ? :)
Apr 19 20:01:39 <Sharwin_F> xD
Apr 19 20:03:27 <PaulFertser> In fact, for FSO devs it'd make sense to keep a list of all kernel interfaces they use directly, so on every api change it'll be trivial to judge whether it affects them and what should be changed. After all, driver-specific stuff can't be standardised, and in the phase of active kernel development it's reasonable to have it changed every now and then. 
Apr 19 20:04:38 <mwester> And the other API changes?  Like the s3c_whatever change?  That's not totally gratituous?
Apr 19 20:05:14 <mwester> And the pwron vs power_on change?   That's not another example of API breakage caused soley by the kernel devs sense of aesthetics?
Apr 19 20:05:24 <mwester> Get real, PaulFertser!
Apr 19 20:06:09 <mwester> The kernel exists to serve userspace, not the other way around.  This is a kernel - an engine - it is not a living room to redecorate because someone doesn't like the spelling or the color of the API.
Apr 19 20:06:16 <PaulFertser> mwester: for the sake of consistency. Generic s3c-ohci driver shouldn't be called s3c2410-ohci. That's obvious. And pwron was a typo. It's better to change things like that earlier than later. And it's trivial to keep up with this. You're making fuss of nothing, imho.
Apr 19 20:06:37 <mwester> The accelerator API should have been deprecated in a controlled manner, with a switch to provide the old sematics.
Apr 19 20:06:43 <mwester> Anything less is laziness.
Apr 19 20:07:23 <mwester> PaulFertser:  I'm making a fuss over significant issues -- see above.
Apr 19 20:07:54 <PaulFertser> mwester: Why bother keeping interfaces that are in flux by definition (of active kernel development) when it's trivial for userspace to switch to new semantics?
Apr 19 20:08:38 <PaulFertser> mwester: i'm not saying you're always making fuss of nothing, but in this kernel api "debate", you're severely exaggerating, imho.
Apr 19 20:10:35 <PaulFertser> mwester: I'd agree with you if it weren't active development phase for the kernel. The fact that it should have ended long time ago is not relevant here.
Apr 19 20:12:04 <PaulFertser> IMHO, again. Don't take me seriously, i'm very pissed by my ISP that is refusing to solve PPPoE stability problems, so i'm probably being inadequately emotional/stupid atm.
Apr 19 20:12:29 <PaulFertser> Sorry for that.
Apr 19 20:16:36 <mwester> PaulFertser:  I'm pretty tired of that attitude re kernel interfaces.
Apr 19 20:16:40 <mwester> Bye.
Apr 19 20:17:56 <FilipBE> PaulFertser: I must say I agree with mwester
Apr 19 20:18:39 <FilipBE> PaulFertser: me as well spent/lost far too much time figuring out why stuff was no longer working, onlyto find out it was caused by changings path/fixing typos etc
Apr 19 20:18:43 * PaulFertser is always wrong. Fuck my life
Apr 19 20:19:59 <FilipBE> PaulFertser: I'm not saying you're always wrong. I just think that case of kernel changes there has to be a real good reaon to change anything
Apr 19 20:20:35 <FilipBE> if it ain't broke, don't fix it. If it needs fixing, document it; especially if it's going to break other programs depending on it
Apr 19 20:20:44 <PaulFertser> FilipBE: for some reason most kernel devs who have commit access disagree with you. As well as do upstream kernel devs.
Apr 19 20:23:48 <playya> i think i have a fix for the bug in fso-monitord. it's caused by the Phone system
Apr 19 20:26:37 <Q-Master> PaulFertser: better to say: "It's my fault" 8)
Apr 19 20:27:23 * Weiss floats an idea: a wiki page of "kernel/other changes which potentially break things", which developers can add to when they break things
Apr 19 20:27:55 <Weiss> then at least there's a central point of reference. as far as i know, i was the only application developer to pick up on the recentl accelerometer changes, for example
Apr 19 20:28:05 <Weiss> and that was only because i pay attention to the right lists
Apr 19 20:33:48 <Q-Master> what is the latest bluez version in FSO and SHR?
Apr 19 20:48:57 <spielc> hey everybody
Apr 19 20:49:08 <spielc> is one of the shr-devs around?
Apr 19 20:54:02 <Zorkman> the battery gadget in the top bar is also rather hard to hit with fingers
Apr 19 23:05:30 <dos1> mickey|dinner: I've tested it. frameworkd doesn't set busy state on resume
Apr 19 23:06:30 <dos1> Ainulindale: I've tested fresh SHR install with quick-and-dirty-dos-splash-screen
Apr 19 23:07:05 <dos1> cat /splash.fb > /dev/fb0
Apr 19 23:08:50 <dos1> I will add check, if loglevel=1 and nice artwork, and package it
Apr 19 23:10:24 <dos1> Works fine, it's all we need I think
Apr 19 23:11:22 <dos1> Booting is still fast and there is no "it-is-booting-or-not?"-effect :)
Apr 19 23:11:54 <dos1> Ok, i'm going to zzz now
Apr 19 23:12:01 <dos1> Good night
**** ENDING LOGGING AT Mon Apr 20 02:59:57 2009