*** Vajb has joined #maemo | 00:11 | |
*** louisdk has quit IRC | 00:15 | |
*** Vajb has quit IRC | 00:16 | |
*** Kilroo has joined #maemo | 00:27 | |
*** dafox has quit IRC | 00:35 | |
*** Vajb has joined #maemo | 00:40 | |
*** Vajb has quit IRC | 00:46 | |
Maxdamantus | 07:19:09 < DocScrutinizer05> kernel LOC 10,118,757(2.6.28)->12,532,667(2.6.32) | 00:47 |
---|---|---|
Maxdamantus | 21926 files changed, 3675432 insertions(+), 1262044 deletions(-) | 00:47 |
Maxdamantus | (git diff --stat v2.6.28 v2.6.32) | 00:47 |
*** Vajb has joined #maemo | 00:48 | |
enyc | Maxdamantus: what about 2.6.28 'stock' to maemo-power 2.6.28 ? | 00:49 |
Maxdamantus | 1321 files changed, 339414 insertions(+), 10614 deletions(-) | 00:49 |
Maxdamantus | oh wait, that's not -power | 00:50 |
Maxdamantus | That's difference between mainline 2.6.28 and stock maemo 2.6.28 | 00:50 |
enyc | Maxdamantus: more to the point, WHICH 2.6.28 version EXACTLY was maemo's kernel based on | 00:50 |
enyc | Maxdamantus: is there 2.6.28.1 2.6.28.2 sort of thing, or does it not work like that ?? | 00:50 |
Maxdamantus | mainline 2.6.28 to -power53 is: 2010 files changed, 374761 insertions(+), 15117 deletions(-) | 00:50 |
Maxdamantus | I guess I can keep comparing the patch releases to find which one is most similar. | 00:51 |
enyc | Maxdamantus: yes please =) kernel.org has 2.6.28 upto 2.6.28.10 | 00:51 |
enyc | Maxdamantus: though does the maemo source just have a release/makefile with the extraversion in it | 00:52 |
Maxdamantus | The initial v2.6.28 release seems to be closest. | 00:54 |
Maxdamantus | https://gist.github.com/Maxdamantus/f2deb46fd06a4b819c292e901c66546c | 00:54 |
Maxdamantus | (the diff is from mainline to maemo 2.6.28 | 00:55 |
Maxdamantus | enyc: no. It has other changes too. | 00:55 |
Maxdamantus | Hm, there's a debian/changelog in my maemo tree with 14k lines in it though. | 00:56 |
Maxdamantus | So just subtract around 15k from all of those "insertions" counts. | 00:57 |
Maxdamantus | Hm. There are also additions under Documentation/arm/OMAP/, so maybe it's actually a fork of some omap branch somewhere. | 00:58 |
enyc | Maxdamantus: post patch/list ?? | 00:58 |
enyc | Maxdamantus: i wonder how much is actually very much patches, and how much is just inserting huge piles of new drivers etc etc... | 00:58 |
Maxdamantus | https://gist.github.com/Maxdamantus/43ab8cefdb22179ff4d36e640cfb96ff | 00:58 |
Maxdamantus | Random modifications to a bunch of the fs drivers further suggests it's not a direct fork from mainline 2.6.28 | 00:59 |
enyc | Maxdamantus: hrrm yes looking myself toooo puzzling | 01:01 |
enyc | Maxdamantus: i wonder whats going on | 01:01 |
enyc | Maxdamantus: that said, key is just to pickout whats' needed atop 2.6.32-latest 'stock' and see if that patches relatively cleanly..... | 01:02 |
enyc | that said, looks like kernel changes to 2.6. 29 30 31 32 added lots of OMAP support/changes anyway ....... good thing or bad thing | 01:09 |
Maxdamantus | I can't find references to various blobs for the `fs` changes in any commits in my repository other than ones relating to N900. | 01:12 |
enyc | humm err arr err | 01:12 |
Maxdamantus | Wonder if kernel.org has a way to search for blobs in .. all repositories .. probably not. | 01:12 |
enyc | dont quit e understand implication | 01:12 |
Maxdamantus | Well, eg: `git rev-parse n900-2.6.28:fs/ext3/super.c` gives back "f4be66e3d62133a36f5b81714aa5f2b16f26e75b" | 01:13 |
enyc | i'm not familaiar wit that rev-parse | 01:13 |
enyc | what is this telling us? | 01:13 |
enyc | that the 2.6.28 changes can't really be found anywhere? | 01:14 |
Maxdamantus | so the 2.6.28 stock maemo kernel has an fs/ext3/super.c file with that checksum (basically; prepend "blob 84547\0" to teh beginning of the file) | 01:14 |
enyc | so whats the significance of those weird blobs on the beginning? | 01:14 |
Maxdamantus | and I can't see that exact file in any reachable commit in my repository other than the ones I've made from those maemo sources and the branches I've fetched from Pali here. | 01:15 |
Maxdamantus | The significance is that I think it indicates that nokia's changes aren't a direct branch from mainline 2.6.28 | 01:15 |
Maxdamantus | and that there's probably another development branch somewhere that they used. | 01:16 |
Maxdamantus | unless they themselves actually did those modifications to `fs` .. I guess that could be plausible, depending on what the changes aro. | 01:16 |
enyc | yes, dothey look significant? | 01:18 |
enyc | i'm thinking .... git // work-in-progress befre 2.6.28 itself released ? | 01:19 |
Maxdamantus | Hm. Some of the changes seem to be from after 2.6.30. | 01:20 |
*** dafox has joined #maemo | 01:20 | |
Maxdamantus | eg, the changes include those from commit 85c7859190c4197a7c34066db14c25903c401187, which is in the mainline master branch, based on v2.6.30-rc8 | 01:22 |
enyc | http://elinux.org/N900#Kernel_git_repository_for_N900 | 01:23 |
enyc | seems to suggest couldn't JUST use a latest 4.12 kernel compile right with old maemo because dsp//powervr drivers | 01:23 |
Maxdamantus | Right, but I think you can use that 4.xx branch to run Maemo. | 01:24 |
Maxdamantus | It's just not compatible with mainline. | 01:24 |
enyc | what you mean? | 01:24 |
enyc | to run stock maemo ?? | 01:24 |
enyc | or slow because driver missing? | 01:25 |
enyc | *confused* | 01:25 |
Maxdamantus | I think you're meant to be able to use https://github.com/pali/linux-n900 to run stock Maemo. I might be mistaken. | 01:25 |
* Maxdamantus has only tried a 3.18 or something kernel from there a year or two ago, and didn't try running stock Maemo. | 01:26 | |
Maxdamantus | actually, 3.14 | 01:26 |
enyc | will pali just tell us what the expected state is?!?!? | 01:26 |
enyc | fwiw, http://people.canonical.com/~mpoirier/n900/2.6.35.10/patches/ <- interesting | 01:27 |
Pali | what is the problem? | 01:28 |
*** florian has quit IRC | 01:28 | |
*** navtis has joined #maemo | 01:30 | |
enyc | Pali: we'd like to know (a) what the limitainso of stock-maemo with a 4.12 etc n900 kernel latest are | 01:30 |
Pali | HW support/kernel drivers is in table on http://elinux.org/N900 | 01:31 |
Pali | you can find in which version was what introduced in mainline kernel | 01:31 |
enyc | Pali: yes, i see 2 red blobs, what practiceal problems that causes? | 01:31 |
enyc | Pali: tidspbridge and PowerVR won't be workable ? | 01:32 |
enyc | Pali: is that it? does that make stock maemo fail because driver unavailable? | 01:32 |
Pali | if you want to run Maemo, look at steps: http://wiki.maemo.org/Porting/Kernel | 01:32 |
Pali | -n900 branches in my git tree contains some patches | 01:33 |
enyc | oooooooooooooh | 01:33 |
Pali | there is ported PowerVR driver | 01:33 |
Pali | fixes for wifi | 01:33 |
Pali | maemo compatibility layer (where still needed) | 01:33 |
Pali | no idea if bluetooth is working... | 01:34 |
Pali | patches for camera are not (finished) in my git repo | 01:35 |
Pali | and tidspbride does not work at all | 01:35 |
enyc | i see didn't know all this | 01:35 |
enyc | whats' the tidspbridge used for? | 01:36 |
Pali | pavelm now playing with camera, so we can expect working camera in new+1 or +2 mainline kernel version | 01:36 |
enyc | i see i see | 01:37 |
enyc | so a workable kernel is well on way...? | 01:37 |
Pali | tidspbridge is bridge driver for TI DSP processor | 01:37 |
enyc | yes, but whats that used for? | 01:37 |
Pali | DSP processor used e.g. for video encoding/decoding | 01:38 |
Pali | maybe there are also applications which uses it for audio | 01:39 |
Pali | or other multimedia processing | 01:39 |
Pali | do not know who else uses DSP in Maemo... if there are more applications in Maemo-Extras | 01:39 |
enyc | right | 01:42 |
*** navtis has quit IRC | 01:42 | |
enyc | talking of wifi, is WPA host / 'hostapd' ever a possibility with that adapter? | 01:43 |
Pali | theoretically with software implementation | 01:45 |
sunshavi | pali: Sebastian Reichel was working on bluetooth. But probably You know that. btw camera is very slow on n900, perhaps pavel version is quicker | 01:45 |
Pali | wifi firmware supports packet injection and monitor mode which should be enough for implementing AP mode | 01:45 |
Pali | wl1251 driver has both support | 01:46 |
Pali | but I do not know any software-based wifi AP implementation | 01:46 |
Pali | IIRC there are some problems with bluetooth on n900, do not know if those problems were fixed or not | 01:47 |
Pali | last time I talked with pavel, he told me that camera for him is working... and I see patches periodically on mailing list | 01:47 |
Pali | so we can expect full-working camera also in mainline | 01:48 |
sunshavi | pali: nice to know | 01:50 |
*** mike727 has joined #maemo | 01:53 | |
*** navtis has joined #maemo | 01:58 | |
*** th652 has quit IRC | 01:59 | |
*** xy2_ has quit IRC | 02:09 | |
*** navtis has left #maemo | 02:10 | |
*** mike727 has quit IRC | 02:13 | |
*** th652 has joined #maemo | 02:20 | |
*** mavhc has quit IRC | 02:34 | |
*** dafox has quit IRC | 02:34 | |
*** xorly has quit IRC | 03:04 | |
*** mavhc has joined #maemo | 03:13 | |
*** Pali has quit IRC | 03:15 | |
*** infobot has quit IRC | 03:19 | |
*** infobot has joined #maemo | 03:20 | |
*** guerby_ has joined #maemo | 04:36 | |
*** guerby has quit IRC | 04:37 | |
*** r00t|home has quit IRC | 04:54 | |
*** r00t|home has joined #maemo | 04:54 | |
*** pagurus has quit IRC | 06:22 | |
*** pagurus has joined #maemo | 06:22 | |
sicelo | software based wifi ap - hostapd? | 07:38 |
DocScrutinizer05 | BUG!! entropy runs dry in maemo5 (internet over WLAN, ssh session established). Though poolsize is 4096, it lingers at 177 and drops from 235 to 177 within minutes | 07:47 |
DocScrutinizer05 | damn! 133 | 07:47 |
DocScrutinizer05 | though this isn't a problem per se it may have security implications. But particularly weird is what actually drains it | 07:49 |
DocScrutinizer05 | processes actually doing blocking read from /dev/random may freeze/lag | 07:50 |
DocScrutinizer05 | suggested measures: find (and fix) the process draining entropy pool. There should be no need for random numbers in normal idle system, IP stack should use its own less valuable source of entropy for sequence numbers etc. | 07:52 |
DocScrutinizer05 | run a process that monitors and - when needed - fills entropy pool from "unusual" sources like the used internet connection itself. E.G from a `iwlist scan` | 07:58 |
DocScrutinizer05 | other possible sources of entropy: bq27200 battery voltage, current; audio sampling from microphone; audio sampling from FM-RX(!) white noise when tuned to no station; accelerometer (poor); ALS (poor, low bitcount). All of the aforementioned only lower significant few bits | 08:03 |
DocScrutinizer05 | the entropy-generating `ls /*` is probably a very poor quality entropy source, given the lack of any mechanical components or quantum effects involved in the whole process | 08:05 |
DocScrutinizer05 | actually this might be one source of hangs in ssh sessions and generally IP traffic | 08:08 |
DocScrutinizer05 | http://paste.ubuntu.com/25094143 | 08:15 |
Maxdamantus | Suggested measures: ln -sf /dev/{u,}random | 08:15 |
Maxdamantus | Because random is practically never useful. | 08:16 |
Maxdamantus | I'm pretty sure ssh won't use /dev/random btw | 08:23 |
Maxdamantus | ssh-keygen might. | 08:23 |
DocScrutinizer05 | freemangordon: ^^^ what do you think? | 08:25 |
Maxdamantus | If only Linux had some sort of CSPRNG that people could read the output of but not the state. | 08:27 |
DocScrutinizer05 | seems I fail to find a way to add to available entropy in /dev/(u)random | 08:32 |
DocScrutinizer05 | this is expected according to https://linux.die.net/man/4/random but it's pretty annoying nevertheless. Could we patch the device drover so it offer some writable node in /proc or /sys to actually *add* to the available entropy pool? http://paste.ubuntu.com/25094214 | 08:36 |
DocScrutinizer05 | also note that `iwlist scan` seems to block the WLAN for a short (0.5s?) period by itself, during which no data traffic is possible | 08:37 |
*** louisdk has joined #maemo | 08:57 | |
DocScrutinizer05 | OHMY | 09:19 |
DocScrutinizer05 | IroN900:~# lsof |grep random | 09:19 |
DocScrutinizer05 | csd 804 root 9r CHR 1,9 1757 /dev/urandom | 09:19 |
DocScrutinizer05 | telepathy 2010 user 9r CHR 1,9 1757 /dev/urandom | 09:19 |
DocScrutinizer05 | browserd 2712 user 12r CHR 1,9 1757 /dev/urandom | 09:19 |
DocScrutinizer05 | browserd 4145 user 12r CHR 1,9 1757 /dev/urandom | 09:19 |
*** th652 has quit IRC | 09:23 | |
DocScrutinizer05 | https://github.com/postmarketOS/pmbootstrap/wiki/nokia-rx51-(Nokia-N900) | 09:24 |
DocScrutinizer05 | >>The first non-Android device! It comes with a hardware keyboard, so one can type in the full disk encryption password directly. It uses pali's 4.6 kernel, which is relatively close to mainline already.<< | 09:26 |
KotCzarny | it might be a bit too much of tinfoil hat, but maybe nokia got crushed by international evil forces for trying to make linux on phones happen | 09:28 |
DocScrutinizer05 | https://ollieparanoid.github.io/post/security-warning/ to cure your tinfoil hat feelings | 10:02 |
DocScrutinizer05 | >>That can be used to turn your device silently into a surveillance device, because these components have direct access to your device's RAM (via DMA)<< not on N900 | 10:03 |
DocScrutinizer05 | at least as far as anybody knows. And for sure not on Neo900 ;-) | 10:04 |
hurrian | One benefit of having a USB^H^H^H HSI modem ;) | 10:13 |
*** Konsieur has joined #maemo | 10:13 | |
DocScrutinizer05 | yes | 10:16 |
DocScrutinizer05 | I couldn't resist editing the nokia-rx51-(Nokia-N900) wiki page ;-D | 10:17 |
DocScrutinizer05 | FOSS radio stack, the most common pipe dream | 10:18 |
DocScrutinizer05 | will *never* happen | 10:19 |
DocScrutinizer05 | and even if id would, I wouldn't dare using it | 10:19 |
DocScrutinizer05 | it* | 10:19 |
hurrian | an open s/w interface to the baseband and AP-managed access is enough though :D | 10:19 |
DocScrutinizer05 | yes | 10:20 |
DocScrutinizer05 | I regret not having bookmarked any of those stories about US citizens sentenced to unspeakable 6 digit fines for using non-certified RF transmitter equipment | 10:22 |
DocScrutinizer05 | like, USD300,000 plus some time in jail iirc | 10:23 |
hurrian | guess that was why having a SDR module embedded in the Neo900 wasn't a design goal? :p | 10:23 |
DocScrutinizer05 | no | 10:23 |
DocScrutinizer05 | SDR is greedy and expensive | 10:24 |
hurrian | yeah, the sheer power and RF board routing requirements would be crazy | 10:24 |
DocScrutinizer05 | and we actually have sort of SDR, for NFC | 10:24 |
hurrian | but then again, so would a phone with a software defined baseband | 10:24 |
DocScrutinizer05 | well, it's not _really_ SDR, it just has a MCU for protocols | 10:26 |
hurrian | the Neo900 has NFC? | 10:26 |
DocScrutinizer05 | yes? | 10:26 |
hurrian | cool, didn't know that. guessing some modification to the back cover would be required? | 10:27 |
DocScrutinizer05 | http://neo900.org/stuff/papers/nfc-draft.pdf | 10:27 |
DocScrutinizer05 | yes, probably. That's why we don't deliver an antenna with it per default | 10:28 |
DocScrutinizer05 | or, we still need to evaluate which antenna we might use | 10:28 |
DocScrutinizer05 | if we're extremely lucky, a flex foil PCB antenna will do | 10:29 |
DocScrutinizer05 | that wouldn't need any massive modificarions to battery lid | 10:29 |
hurrian | my guess is reuse of one of those wireless charging receiver+NFC coils for Android (usually Samsung) phones | 10:30 |
DocScrutinizer05 | :nod: | 10:30 |
DocScrutinizer05 | that sort of stuff | 10:30 |
DocScrutinizer05 | it's RF. so voodoo, so only possible to test in real device | 10:31 |
hurrian | and maybe bring two pogo pins through the back case of the N900, hoping they get close enough to the pads of said wireless charger pad | 10:31 |
DocScrutinizer05 | umm | 10:31 |
DocScrutinizer05 | http://neo900.org/stuff/papers/hb.pdf | 10:32 |
DocScrutinizer05 | NFC_GND, NFC_ANT | 10:32 |
hurrian | yep, something like that | 10:33 |
hurrian | imagine how much fun could be had though given a few hundred thousand USD more in tooling (e.g. for plastic molds) could go- 5/6 inch N900? | 10:34 |
DocScrutinizer05 | http://neo900.org/stuff/papers/hb.pdf#10 >> 4.3 Mechanical coupling with battery cover<< | 10:34 |
*** florian has joined #maemo | 11:00 | |
*** florian has quit IRC | 11:05 | |
*** xorly has joined #maemo | 11:07 | |
*** aloril_ has quit IRC | 11:17 | |
*** Pali has joined #maemo | 11:49 | |
*** xy2_ has joined #maemo | 12:43 | |
*** NeKit has joined #maemo | 13:29 | |
*** TheKit has quit IRC | 13:31 | |
*** xy2_ has quit IRC | 13:43 | |
*** florian has joined #maemo | 14:02 | |
*** xy2_ has joined #maemo | 14:05 | |
*** florian has quit IRC | 14:11 | |
*** florian has joined #maemo | 14:20 | |
*** aloril has joined #maemo | 14:59 | |
sicelo | oh gosh ... our mobile operator does not isolate clients, ie i can connect to other phones if they have any running services | 15:33 |
sicelo | surely that's wrong? | 15:33 |
KotCzarny | money stealer | 15:44 |
KotCzarny | unless you dont get charged for incoming packets | 15:45 |
KotCzarny | which is unlikely ;) | 15:45 |
KotCzarny | udp flood someone ;) | 15:46 |
sicelo | you don't get charged | 15:57 |
*** chfoo[m] has quit IRC | 15:59 | |
*** chfoo[m] has joined #maemo | 16:04 | |
*** Natch has quit IRC | 16:08 | |
Maxdamantus | "connect" as in just a normal TCP connection? | 16:11 |
Maxdamantus | Presumably it should be the responsibility of the OS to not allow the ISP or anyone who happens to be on the internet to do bad things to it. | 16:11 |
Maxdamantus | I imagine it would be unreasonable to make a phone OS that assumes it's always behind some NAT/firewall provided by the ISP. | 16:12 |
Maxdamantus | I would also imagine the same set of "services" would generally be exposed over WiFi. | 16:14 |
KotCzarny | i would be afraid about possible costs of not putting phone behind the nat | 16:16 |
Maxdamantus | How would these "services" work behind a NAT anyway? | 16:22 |
KotCzarny | stun | 16:24 |
*** florian has quit IRC | 16:25 | |
sicelo | connect normal tcp connection .. yes. i can ssh my n900 from ny laptop using usb dongle with same cellular operator | 16:39 |
DocScrutinizer05 | LOL | 17:05 |
*** Vajb has quit IRC | 17:10 | |
sicelo | at least it doesn't charge anything | 17:14 |
*** Vajb has joined #maemo | 17:32 | |
*** Vajb has quit IRC | 17:40 | |
*** Vajb has joined #maemo | 17:58 | |
sicelo | thebpower consumption though! | 18:00 |
KotCzarny | run tcpdump on it? :) | 18:00 |
sicelo | just tested ... running an 'htop' this way makes standby current draw to rise to 200mA with screen off | 18:01 |
*** Vajb has quit IRC | 18:03 | |
*** mavhc has quit IRC | 18:33 | |
*** mavhc has joined #maemo | 18:35 | |
*** Vajb has joined #maemo | 18:35 | |
*** mavhc has quit IRC | 18:36 | |
*** mavhc has joined #maemo | 18:37 | |
*** Vajb has quit IRC | 18:40 | |
DocScrutinizer05 | inbound pings and other shite can't get blocked, the modem _has_to_ send ack | 18:52 |
*** Vajb has joined #maemo | 18:52 | |
DocScrutinizer05 | the only way to stop is to disable the APN | 18:53 |
*** LjL has quit IRC | 19:05 | |
sicelo | inbound pings are actually blackholed by default on n900on gprs0, but allowed on the other connections | 19:06 |
sicelo | /etc/network/if-up.d/00_disable_icmp_echo_reply | 19:08 |
*** Vajb has quit IRC | 19:10 | |
*** xorly has quit IRC | 19:14 | |
*** Vajb has joined #maemo | 19:18 | |
DocScrutinizer05 | inbound data package needs an ACK always, on GPRS OTA protocol, independent from TCP OR IP or whatever | 19:23 |
DocScrutinizer05 | afaik | 19:23 |
*** LjL has joined #maemo | 19:24 | |
DocScrutinizer05 | think of it as an ethernet through GPRS/UMTS tunnel | 19:24 |
*** Vajb has quit IRC | 19:34 | |
*** Konsieur has quit IRC | 19:40 | |
*** xy2_ has quit IRC | 19:44 | |
*** xy2_ has joined #maemo | 19:44 | |
*** Vajb has joined #maemo | 19:46 | |
*** florian has joined #maemo | 19:48 | |
*** xy2_ has quit IRC | 19:52 | |
*** Vajb has quit IRC | 19:57 | |
*** Vajb has joined #maemo | 19:57 | |
*** florian has quit IRC | 20:02 | |
*** Vajb has quit IRC | 20:06 | |
*** xy2_ has joined #maemo | 20:19 | |
*** sfa has joined #maemo | 20:28 | |
*** sfa has quit IRC | 20:29 | |
*** Vajb has joined #maemo | 20:33 | |
*** Vajb has quit IRC | 20:44 | |
*** Vajb has joined #maemo | 20:46 | |
*** Vajb has quit IRC | 20:51 | |
*** Vajb has joined #maemo | 21:14 | |
*** Vajb has quit IRC | 21:24 | |
*** florian has joined #maemo | 21:32 | |
*** frals has quit IRC | 21:35 | |
*** frals has joined #maemo | 21:40 | |
*** frals has joined #maemo | 21:40 | |
*** Vajb has joined #maemo | 21:49 | |
*** Vajb has quit IRC | 21:53 | |
*** xy2_ has quit IRC | 22:00 | |
*** msava has joined #maemo | 22:05 | |
*** xy2_ has joined #maemo | 22:05 | |
*** xes_ has joined #maemo | 22:11 | |
*** xes has quit IRC | 22:13 | |
*** msava has quit IRC | 22:17 | |
*** msava has joined #maemo | 22:18 | |
*** Vajb has joined #maemo | 22:18 | |
*** Vajb has quit IRC | 22:25 | |
*** Vajb has joined #maemo | 22:25 | |
*** Vajb has quit IRC | 22:29 | |
*** Vajb has joined #maemo | 22:30 | |
*** Vajb has quit IRC | 22:39 | |
*** Vajb has joined #maemo | 22:41 | |
*** Vajb has quit IRC | 22:46 | |
*** frals has quit IRC | 22:46 | |
*** Vajb has joined #maemo | 22:46 | |
*** Vajb has quit IRC | 22:51 | |
*** frals has joined #maemo | 22:57 | |
*** frals has joined #maemo | 22:57 | |
*** Vajb has joined #maemo | 23:09 | |
*** merlin1991 has quit IRC | 23:17 | |
*** merlin1991 has joined #maemo | 23:17 | |
*** Vajb has quit IRC | 23:18 | |
*** Vajb has joined #maemo | 23:48 | |
*** dafox has joined #maemo | 23:48 | |
*** Vajb has quit IRC | 23:54 | |
*** Vajb has joined #maemo | 23:55 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!