**** BEGIN LOGGING AT Wed Sep 29 02:59:57 2010
Sep 29 05:21:20 <creeper_> good morning
Sep 29 06:43:54 <JaMa|Zzz> moin
Sep 29 07:09:19 <JaMa|Zzz> what tool do you use to interactive rcs conflicts merge?
Sep 29 07:46:57 <[Rui]> good morning!
Sep 29 09:12:58 <daniele_athome> morning
Sep 29 09:54:11 <JaMa> who is mostly maintaining palmpre in OE? 
Sep 29 09:57:06 <mrmoku> JaMa: I would think morphis
Sep 29 11:29:06 <pespin> mrmoku, I think we didn't finally add recipe for new evopedia (rewritten in qt) version. Could you please try bitbaking this and pushing it to oe + shr-u repos? http://espeweb.net/misc/openmoko/recipes/evopedia_git.bb
Sep 29 11:31:52 <Q-Master> JaMa: after update e claims that it can't open appshadow.
Sep 29 13:14:55 <playya__> JaMa, do you own a palm pre?
Sep 29 13:53:34 <[Rui]> phonelog is crashing me xserver
Sep 29 13:54:53 <creeper_> [Rui]: shr-u?
Sep 29 13:55:06 <[Rui]> yeah
Sep 29 13:55:16 <creeper_> will try on mine
Sep 29 13:55:45 <[Rui]> not deterministic
Sep 29 13:55:57 <creeper_> sure that it is phonelog then?
Sep 29 13:56:03 <[Rui]> yeah
Sep 29 13:56:17 <creeper_> my xserver just crashed just having tangogps open
Sep 29 13:56:36 <[Rui]> two times when pressing the received calls tab
Sep 29 13:56:47 <[Rui]> once on pressing the dialed calls tab
Sep 29 13:56:56 <creeper_> and it happened quite a few times that it crashed while i was listening to podcasts and not touching anything
Sep 29 13:57:04 <[Rui]> after having pressed withou a problem the received calls tab
Sep 29 13:57:33 <creeper_> ok, my xserver just crashed :P
Sep 29 13:57:42 <creeper_> pressed around in phonelog a few times
Sep 29 13:57:59 <creeper_> any way to get it back without usb and rebooting? i suppose not?
Sep 29 13:58:17 <[Rui]> without usb? toast :)
Sep 29 13:59:02 <creeper_> ah, but the 8 second patch is in again, at least :)
Sep 29 14:00:31 <[Rui]> 8snd?
Sep 29 14:03:27 <creeper_> 8 second power press to turn off the phone instead of having to remove the bat
Sep 29 14:03:36 <JaMa> playya__: no, just build fails on buildhost
Sep 29 14:03:53 <JaMa> | loadkeys --mktable drivers/char/defkeymap_joplin.map > drivers/char/defkeymap.c.tmp
Sep 29 14:03:56 <JaMa> | /bin/sh: loadkeys: command not found
Sep 29 14:04:05 <JaMa> in kernel! NOTE: package linux-palmpre-2.6.24+gitr0+96eba42952e860f652e66a72569319dfd35756dc-r90: task do_compile: Failed
Sep 29 14:04:18 <JaMa> Q-Master: did you read the email about efl bump?
Sep 29 14:04:26 <[Rui]> ah it's back... cool
Sep 29 14:04:38 <Q-Master> JaMa: not sure.
Sep 29 14:05:16 <JaMa> Q-Master: http://lists.shr-project.org/pipermail/shr-user/2010-September/006381.html
Sep 29 14:06:10 <playya__> JaMa, oh. that's bad. I'll check later when i start my build
Sep 29 14:06:43 <JaMa> playya__: thx
Sep 29 14:06:47 <Q-Master> JaMa: ah. this... I've read it. But after removing .e from homedir the problem began. I've checked and the real problem is that /var/volatile/appshadow is not created during the boot
Sep 29 14:07:59 <JaMa> Q-Master: then check initscripts-shr version
Sep 29 14:08:44 <JaMa> Q-Master: also read [Shr-User] X.org broken after reboot
Sep 29 14:09:14 <JaMa> hmm maybe it was in other thread
Sep 29 14:09:45 <Q-Master> JaMa: initscripts-shr - 0.0.1-r19.5
Sep 29 14:10:06 <JaMa> then it should be created fine
Sep 29 14:11:11 <JaMa> htcdream is using /home/shr/shr-unstable/openembedded/recipes/linux/linux-nios2_2.6.34.bb ? or at least it tries to build it on shr buildhost..
Sep 29 14:19:37 <dos1> JaMa: seems that there is something wrong with initscripts-shr
Sep 29 14:19:47 <dos1> it didn't worked for me on n900 too, i'll try today on gta02
Sep 29 14:20:39 <JaMa> dos1: don't know.. it worked for me 3 reflashes on gta02, one on spitz and n900
Sep 29 15:36:05 <CIA-59> freesmartphone.org: 03seba.dos1 07cornucopia * r2f4019d768ee 10/fsodeviced/conf/openmoko_gta/Makefile.am: fsodeviced: conf: openmoko_gta: set alsa-2.6.34 as default
Sep 29 15:36:09 <dos1> JaMa: as you wanted ^^^^^
Sep 29 16:07:40 <rohezal> Weiss: hi
Sep 29 16:07:59 <Weiss> rohezal: evening
Sep 29 16:08:46 <rohezal> Weiss: just to make I understand the idea: the X Server has a pixmap handle. The kernel knows what the pixmap is about. When dri change the pixmap via the kernel, the kernel will tell the X server.
Sep 29 16:08:55 <morphis> heyho
Sep 29 16:09:09 <rohezal> Weiss: something like: Hey the pixmap is not 160*120 its notw 320*240 right?
Sep 29 16:09:55 <Weiss> rohezal: kind of.. with DRI you can only write TO the pixmap, and not change its size. there would be one pixmap and one extra kernel-level buffer involved
Sep 29 16:10:47 <Weiss> you write the low-res version to a kernel buffer (much easier than it sounds), then send a command sequence to the kernel to scale it up, then tell X to swap front<->back buffers on the pixmap
Sep 29 16:11:46 <rohezal> Weiss: but how does the xserver knows about the new pixmap? can i just give him the handle of the pixmap i got from the kernel via DRI?
Sep 29 16:12:51 <Weiss> no new pixmap is created..
Sep 29 16:13:26 <Weiss> DRI allows you to ask the X server for the kernel handle of the pixmap you're drawing to. the one you write the low-res version to is different
Sep 29 16:13:44 <rohezal> ahh ok
Sep 29 16:14:03 <rohezal> Weiss: so i create a big pixmap on the gpu. then push a small pixmap to the kernel
Sep 29 16:14:43 <rohezal> Weiss: then the small pixmap is copied to the gpu and the kernel sends the scale command. right? and the scaled pixmap is written into the x server pixmap
Sep 29 16:15:03 <rohezal> Weiss: right?
Sep 29 16:16:55 <Weiss> ish... all the pixmaps were always in the GPU, the difference is how you write data to them
Sep 29 16:17:16 <rohezal> Weiss: <- sry X noob :(
Sep 29 16:18:00 <rohezal> Weiss: so i copy a small pixmap to the gpu, then tell the kernel, write the pixmap to this bigpixmap and scale it. the x server has a handle to the big pixmap
Sep 29 16:18:50 <rohezal> Weiss: and the kernel will use for writing the small Pixmap to the big Bixmap the hardware scalebklit function
Sep 29 16:18:54 <rohezal> Weiss: right?
Sep 29 16:19:20 <Weiss> the exact sequence of events would be:
Sep 29 16:20:20 <Weiss> client tells server to open a window. server requests the kernel to allocate GPU memory for the window and maybe draws some kind of grey background or something
Sep 29 16:20:45 <morphis> JaMa: ping
Sep 29 16:20:47 <Weiss> that's the same for all windows(/pixmaps) regardless of whether DRI is involved (or in fact, if any acceleration at all is involved)
Sep 29 16:21:21 <Weiss> then the client asks the kernel to allocate some GPU memory for the small version, then asks the kernel to map that bit of GPU memory into its own address space so it can draw something onto it
Sep 29 16:21:45 <Weiss> then the client asks the server for a copy of the kernel's handle for the window pixmap
Sep 29 16:22:14 <Weiss> then it sends a command sequence to the kernel using the window pixmap handle and the small version handle, telling it to do the scaling
Sep 29 16:23:14 <Weiss> however, when the client asked the server for a copy of the window pixmap handle, it actually gave it a handle to a back buffer, and not the thing that really ends up on the screen
Sep 29 16:23:36 <Weiss> so, finally the client asks the X server to swap the buffers, i.e. to copy the contents of the back buffer to the front buffer
Sep 29 16:24:36 <rohezal> *reading and trying to understand* :)
Sep 29 16:25:52 <rohezal> ok cool
Sep 29 16:26:41 <Weiss> hopefully the amount of faffing involved with this takes less time than it would have taken just to write the big version straight to the screen
Sep 29 16:26:54 <rohezal> thats exactly what i need :). can we chose to copy the scaled image to a specific localtion on the backbuffer? like in the middle and let black border around the image
Sep 29 16:27:04 <rohezal> hmmm 
Sep 29 16:27:17 <rohezal> i dont know, but a 640x480 picture is realy big
Sep 29 16:27:46 <rohezal> i got fullspeed at 160x144 and half speed at 320x240 (when i use framskip of 2 i got almost fullspeed back)
Sep 29 16:27:58 <rohezal> its realy the bus from cpu to gpu which is so slow
Sep 29 16:28:29 <rohezal> cant even think about about 640x480 ... but with this fix it sounds good. 
Sep 29 16:28:56 <Weiss> you're scaling from 160x144 all the way up to 640x480?
Sep 29 16:29:05 <rohezal> do you think it would add much over to pass the handles from server to client, call the scale function and call the swap buffer functions?
Sep 29 16:29:20 <rohezal> no i dont, i scale from 160x144 to 320x240
Sep 29 16:29:49 <rohezal> which is from more then full speed to half speed... with only every second frame passed to the gpu almost fullspeed
Sep 29 16:30:18 <rohezal> i dont use hw acceleration, i render a picture on the cpu and then just copy it 
Sep 29 16:30:27 <Weiss> so.. 1/4 of the bandwidth
Sep 29 16:30:52 <Weiss> do you want to do 160 all the way to 640, or are you running in QVGA mode?
Sep 29 16:32:03 <rohezal> wait, vga is 640x480 and qvga is 320x240
Sep 29 16:32:05 <rohezal> right?
Sep 29 16:32:11 <rohezal> gamerunner runs in 640x480
Sep 29 16:33:29 <Weiss> yep
Sep 29 16:42:44 <rohezal> ok 
Sep 29 16:43:09 <rohezal> the documentation you got, is it the NDA documentation?
Sep 29 16:43:46 <Weiss> yep
Sep 29 16:49:24 <rohezal> hmmm i can i get them too? this thing is interessting enough, im studyng computer science
Sep 29 16:49:32 <rohezal> and need a topic for my bachelor thesis
Sep 29 16:49:41 <rohezal> next year
Sep 29 17:00:13 <PaulFertser> leviathan: you know i've read several books on FR with FBReader and it was decent experience. Once you choose a suitable font and color, that's really ok, and doesn't hurt the eyes.
Sep 29 17:01:34 <DocScrutinizer51> mooo
Sep 29 17:02:58 <DocScrutinizer51> PaulFertser: interested to have a look at winner of my private ungly scripts contest? :-D
Sep 29 17:03:09 <PaulFertser> DocScrutinizer51: hehe, yes
Sep 29 17:06:20 <DocScrutinizer51> http://talk.maemo.org/showthread.php?t=62731&page=7
Sep 29 17:09:09 <DocScrutinizer51> still gasping...
Sep 29 17:10:44 <PaulFertser> DocScrutinizer51: ahem, but what is the usecase? :)
Sep 29 17:11:21 <DocScrutinizer> not really sure, sth like finding free channels for FMTX stereo link?
Sep 29 17:13:09 <PaulFertser> DocScrutinizer: well, if i was to use the FM transmitter, i'd first turn on my fm stereo, pressed >> until i see a free frequency (and i think i know where those are usually available) and then just use. I'd have to tune my stereo to the chosen freq anyway, and that script only eliminates little work, doesn't it?
Sep 29 17:13:18 <PaulFertser> DocScrutinizer: probably i'm not understanding something.
Sep 29 17:13:23 <DocScrutinizer> if [guiyn]; then echo bla; fi; sleep 1; if [guiyn]; then echo bla1; fi
Sep 29 17:14:08 <DocScrutinizer> PaulFertser: nah, you're probably absolutely right
Sep 29 17:15:17 <DocScrutinizer> fn() {xxx}; mainvar1=7; echo here is main; fn2(){yyy}
Sep 29 17:15:47 <DocScrutinizer>  a particularly nice one: rans=$(zenity -entry-text "root" --title "you must be root"...); eval $rans
Sep 29 17:16:20 <DocScrutinizer> incredible
Sep 29 17:17:21 <DocScrutinizer> zexit() {if [$?]; then exit 1; fi)
Sep 29 17:18:25 <mrmoku> heh
Sep 29 17:19:13 <DocScrutinizer> even
Sep 29 17:19:22 <DocScrutinizer> zexit() {if [$? -eq 1]; then exit 1; fi)
Sep 29 17:20:04 <PaulFertser> DocScrutinizer: oh my, the art of scripting seems to be lost.
Sep 29 17:20:13 <DocScrutinizer> and the clear winner iiiiiiiiiiiiis.....
Sep 29 17:23:53 <mrmoku> DocScrutinizer: that's not fair... just tell us the winner please :P
Sep 29 17:24:08 <DocScrutinizer> BLIZZARD
Sep 29 17:24:57 <CIA-59> freesmartphone.org: 03daniele.athome 07libfreesmartphone-glib * r9fb590caf344 10/ (7 files in 3 dirs): 
Sep 29 17:24:58 <CIA-59> freesmartphone.org: Added PIM.Message family
Sep 29 17:24:58 <CIA-59> freesmartphone.org: Signed-off-by: Daniele Ricci <daniele.athome@gmail.com>
Sep 29 17:30:24 <GNUtoo|laptop> hi mrmoku 
Sep 29 17:30:37 <GNUtoo|laptop> could you rebase or learn me to rebase a remote branch on top of the current branch?
Sep 29 17:32:49 <PaulFertser> GNUtoo|laptop: rebase remote branch on top of the current?
Sep 29 17:33:00 <PaulFertser> GNUtoo|laptop: remote branches are for tracking remote repos.
Sep 29 17:33:03 <PaulFertser> afaict
Sep 29 17:33:23 <GNUtoo|laptop> rebase the org.openembedded.dev against the n900 local branch which track a remote n900 branch
Sep 29 17:33:38 <GNUtoo|laptop> but I was said to cherry-pick
Sep 29 17:34:26 <PaulFertser> GNUtoo|laptop: probably we're using different terminology here. Git repos have two types of branches: local and "remote" where remote branches are the same but they're set up in a way to "track" branches from "remote repositories".
Sep 29 17:34:45 <mrmoku> GNUtoo|laptop: do the following (while having n900 checked out)
Sep 29 17:34:54 <mrmoku> a) git fetch origin 
Sep 29 17:35:03 <mrmoku> b) git merge origin/org.openembedded.dev
Sep 29 17:35:15 <daniele_athome> http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.PIM.Message.html;hb=HEAD#GetMultipleFields
Sep 29 17:35:16 <mrmoku> c) git rebase origin/org.openembedded.dev
Sep 29 17:35:24 <daniele_athome> guys should that method return something?
Sep 29 17:35:34 <GNUtoo|laptop> mrmoku, thanks a lot
Sep 29 17:35:46 <PaulFertser> mrmoku: are you sure merging before rebasing makes sense?
Sep 29 17:35:53 <mrmoku> GNUtoo|laptop: yw. sorry. for not being of help the last days... but I'm overloaded with daywork
Sep 29 17:36:12 <GNUtoo|laptop> ok
Sep 29 17:36:17 <mrmoku> PaulFertser: well... it works that way... if it makes sense... no idea :P
Sep 29 17:36:33 <PaulFertser> mrmoku: i mean why merge before rebase, what is that meant for?
Sep 29 17:37:19 <PaulFertser> GNUtoo|laptop: so your question probably was "how to rebase my local branch on top of the remote tracking branch". :)
Sep 29 17:37:39 <GNUtoo|laptop> PaulFertser, no
Sep 29 17:37:51 <GNUtoo|laptop> that's easy and I do it all the time
Sep 29 17:38:07 <GNUtoo|laptop> the question was how to rebase the remote tracking branch against my local branch
Sep 29 17:38:19 <GNUtoo|laptop> basically I take changes from remote
Sep 29 17:38:31 <mrmoku> PaulFertser: we have two remotes
Sep 29 17:38:33 <GNUtoo|laptop> and not changes locally rebased on top of them
Sep 29 17:43:09 <PaulFertser> GNUtoo|laptop: i'm sorry, i do not understand you. The recipe suggested by mrmoku looks like simple rebasing of local branch on top of the latest version of the remote-tracking branch.
Sep 29 17:45:02 <PaulFertser> GNUtoo|laptop: changing remote tracking branches doesn't make any sense because they exist for the sole purpose of tracking branches in remote repositories.
Sep 29 17:46:07 <CIA-59> freesmartphone.org: 03daniele.athome 07libfreesmartphone-glib * r51e786fd4c34 10/ (src/dbus-types.h xml/org.freesmartphone.PIM.Message.xml): 
Sep 29 17:46:08 <CIA-59> freesmartphone.org: Fix PIM.Message.GetMultipleFields
Sep 29 17:46:08 <CIA-59> freesmartphone.org: Signed-off-by: Daniele Ricci <daniele.athome@gmail.com>
Sep 29 17:46:12 <mrmoku> PaulFertser: we rebase, but not on the tracking branch... onto a branch of a different remote
Sep 29 17:46:19 <mrmoku> dunno if that matters though
Sep 29 17:46:36 <PaulFertser> mrmoku: you can't rebase on a branch that doesn't exist in your repo.
Sep 29 17:46:48 <daniele_athome> mickey|away, can i fix it in specs?
Sep 29 17:46:53 <mrmoku> PaulFertser: it exists
Sep 29 17:47:19 <PaulFertser> mrmoku: man git-branch: "-r List or delete (if used with -d) the remote-tracking branches."
Sep 29 17:47:23 <mrmoku> PaulFertser: and I think merging beforehand is good to resolve eventual conflicts
Sep 29 17:47:53 <PaulFertser> mrmoku: my guess would be that merging beforehand is a noop in the end basically.
Sep 29 17:49:12 <mrmoku> hmm... yeah, you're right probably
Sep 29 17:49:30 <mrmoku> makes no difference if I resolve them by merging before or during the rebase
Sep 29 17:51:17 <PaulFertser> mrmoku: the merge commit will be the last one in the set of the commits to be rebased, so i'm afraid you would have to resolve conflicts twice in fact: on merging and then on rebasing.
Sep 29 17:53:40 <PaulFertser> mrmoku: when merging you do not change any previous commit, but you add a new one (with metadata specifying which heads were merged) and that is the state of the repository after resolving conflicts. But rebasing is like exporting all commits to be rebased as patch series and applying them one by one on top of the choosen commit. At least that's how i understand that.
Sep 29 17:54:33 <PaulFertser> mrmoku: do not forget that every commit is in fact the state of all the sources at a given moment, it's not the diff! Diffs are derived from any two given states of the sources later when you ask for them.
Sep 29 17:55:21 <PaulFertser> mrmoku: and every commit has a metadata entry that says who was its ancestor, and that's how the history is formed.
Sep 29 17:56:44 <mrmoku> PaulFertser: yup, I know all that... dunno why I did that merging before
Sep 29 18:21:21 <onen|openBmap> hey guys
Sep 29 18:21:30 <onen|openBmap> mrmoku: hallo
Sep 29 18:22:21 <onen|openBmap> mrmoku: you made a patch to obm client, in order to fix the crash at the startup, because of GetInfo method being not available on org.freesmartphone.GSM.Device 
Sep 29 18:22:50 <DocScrutinizer> PaulFertser: isthere any git micro_howto explaining things and needed cmds in a 30 sentences like your prev post?
Sep 29 18:23:02 <onen|openBmap> mrmoku: I had a look at the current api, and don't see the data this called had, anywhere... has this method been removed, or simply moved, and I missed it?
Sep 29 18:24:04 <mrmoku> onen|openBmap: hey
Sep 29 18:24:05 <DocScrutinizer> hi onen|openBmap 
Sep 29 18:24:21 <mrmoku> onen|openBmap: don't remember out of the box... let me check
Sep 29 18:24:39 <onen|openBmap> DocScrutinizer: hallo! I have read you met some difficulties with usb host on n900, sad news :-(
Sep 29 18:24:52 <DocScrutinizer> onen|openBmap: not really
Sep 29 18:25:01 <onen|openBmap> DocScrutinizer: ah? good then :-)
Sep 29 18:25:37 <onen|openBmap> DocScrutinizer: I am waiting for the meego summit next month, I am curious to see if new devices will be announced
Sep 29 18:26:04 <onen|openBmap> DocScrutinizer: together with release in october of new version of meego, and a possibly image for the n900
Sep 29 18:26:06 <DocScrutinizer> mohammad's method (which was our first and so far only success back in May) turned out to do a fake HNP instead of a proper FORCE_HOST. Everything else is fine
Sep 29 18:26:26 <mrmoku> onen|openBmap: it moved to org.freesmartphone.Info
Sep 29 18:26:28 <mrmoku> http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Info.html;hb=HEAD#GetInfo
Sep 29 18:27:05 <onen|openBmap> DocScrutinizer: wow, you lost me there ;-) so basically, you though it worked, but it did not, but since then, you succeeded in making work anyway. is that correct?
Sep 29 18:27:09 <pespin> mrmoku, did you have time to look at the new evopedia recipe? :)
Sep 29 18:27:19 <mrmoku> pespin: no, sorry... won't be able today
Sep 29 18:27:28 * mrmoku has a serious daywork overload :/
Sep 29 18:27:41 <pespin> mrmoku, ok np. do you want me to remember it in two days or so?
Sep 29 18:28:09 <mrmoku> pespin: yeah, remember me tomorrow... I hope to have finished until then
Sep 29 18:28:38 <onen|openBmap> mrmoku: stupid me! I have seen this one, but ran through the documentation, and saw no of the expected fields (which is normal, because it is device specific). And I did not realise this might be actually the one
Sep 29 18:28:54 <onen|openBmap> mrmoku: thanks, I add a patch then
Sep 29 18:28:54 <DocScrutinizer> it worked somehow, and recently a lot of people made it work for them, but it uses a highly random method, prone to fail on unknown minimaql variations of whole setup. Anyway we now got some proper logs, and I seem to have had a first success in doing a proper FORCE_HOST based hostmode, some 2 days ago
Sep 29 18:29:16 <DocScrutinizer> need to look deeper into it tonight, hope I'll find the time for it
Sep 29 18:29:19 <mrmoku> onen|openBmap: ok, great
Sep 29 18:29:34 <PaulFertser> DocScrutinizer: i'm not sure. And i usually have to look at the git man pages quite often.
Sep 29 18:29:45 <onen|openBmap> got to go. bbl
Sep 29 18:29:50 <DocScrutinizer> cya
Sep 29 18:34:39 <[Rui]> hi again
Sep 29 19:29:45 <Wonka> is there any sense in trying out current shr-kms?
Sep 29 19:30:03 <Wonka> does it do GPRS, GPS?
Sep 29 19:30:59 <JaMa> yes it does
Sep 29 19:31:58 <Wonka> 'cause shr-u from some days ago didn't do GPRS
Sep 29 19:32:03 <JaMa> Wonka: you only need to use newer fsodeviced or copy newer alsa states for working headset
Sep 29 19:32:21 <JaMa> Wonka: ah, it won't help with GPRS issue..
Sep 29 19:32:29 <JaMa> for some reason I've read it as GSM/GPS
Sep 29 19:32:54 <Wonka> currently, I don't need telephony or other sound... I want GPS and GPRS for geocaching
Sep 29 19:33:12 <Wonka> and I could use some fsck.jffs2 I think
Sep 29 19:35:22 <Wonka> https://chaos.in-kiel.de/~w/openmoko/jffs2-BUG.dmesg
Sep 29 21:02:56 <[Rui]> Wonka: there's a GPRS issue but since mickey|away is on vacation we can't expect a solution that soon :(
Sep 29 21:03:23 <Wonka> [Rui]: hmf :/
Sep 29 21:03:39 <[Rui]> Wonka: I feel your pain, I'm paying 5€ per month that have just been paid :|
Sep 29 21:04:05 <Wonka> well, my ooooold shr-u still works...
Sep 29 21:04:22 <[Rui]> but I'm sure it has other problems :)
Sep 29 21:04:27 <Wonka> but I'd like something current every now and then, because the current stuff does use soooo much less battery.
Sep 29 21:04:57 <[Rui]> Now my battery lasts a lot longer indeed (without gprs *chuif*)
Sep 29 21:05:00 <Wonka> .oO(the current stuff has much lower current, haha )
Sep 29 21:05:19 <Wonka> the more current, the less current
Sep 29 21:05:57 <[Rui]> those dull dozing moments of stupid meetings filled with cockfights only go so faster with a gprs connection to identi.ca :)
Sep 29 21:06:10 <Wonka> haven't found some _useable_ WM in debian...
Sep 29 21:06:27 <[Rui]> Wonka: not even e17+illume?
Sep 29 21:06:31 <Wonka> and not gotten gprs running in debian either.
Sep 29 21:06:42 <Wonka> nope, some weirdness with font sizes there
Sep 29 21:07:08 <Wonka> looks like e17+illume in shr-u, but completely different
Sep 29 22:12:58 <CIA-59> SHR: 03pespin.shar 07shr-settings * r6ef8b3a39f8a 10/shr_settings_modules/shr_timezone.py: [Timezone] changed hoversel for inwin. I couldn't get the List to show, so I implemented it with an array of buttons. Would be good to have it with a List + Index though.
Sep 29 23:09:34 <Serdar> can we think about a description about the "hackable mobile devices" devroom?
Sep 29 23:48:38 <playya__> Serdar, which congress/conference?
Sep 29 23:48:51 <Serdar> FOSDEM11
Sep 29 23:48:56 <Serdar> I sent a mail again
**** ENDING LOGGING AT Thu Sep 30 02:59:57 2010