=== bjf is now known as bjf[afk] | ||
=== zul_ is now known as zul | ||
neur0n | hello? | 00:56 |
---|---|---|
dsfg | can anyone answer a computery question | 03:27 |
jjohansen | dsfg: I can try | 03:29 |
dsfg | it's a dumb question and not about ubuntu | 03:29 |
dsfg | but how reliable is the info you get when you lookup an IP address to see which country it;s in? | 03:29 |
virtuald | not reliable at all since you can use a proxy or other form of tunnel, but i think it's usually right | 03:31 |
dsfg | ok im trying to find out where a person is, i got his IP | 03:32 |
dsfg | and he is really dumb with computers | 03:32 |
dsfg | so i dont think he even knows what a proxy is | 03:32 |
dsfg | i just want to see if he's lying about being in california on vacation, when i look up his IP it confirms he is lying but maybe the IP is lying | 03:32 |
dsfg | instead | 03:32 |
jjohansen | dsfg: its fairly reliable, if there isn't a proxy | 03:32 |
dsfg | everywhere says the IP is on costa rica, so should i trust that? | 03:33 |
dsfg | i know he isnt smart enouhg to use a proxy | 03:33 |
dsfg | but is there anything else that would cause a perosns IP to be in costa rica | 03:33 |
jjohansen | dsfg: well there is potentially bugs, or cache poisoning | 03:36 |
dsfg | but for the most part it's reliable? | 03:36 |
jjohansen | err make that stale cache | 03:36 |
jjohansen | yes | 03:36 |
dsfg | IP depends on your ISP not your computer right? | 03:37 |
dsfg | i hope that question makes sense | 03:37 |
jjohansen | yes, mostly depends on your ISP | 03:37 |
dsfg | so, if someone had a laptop they bought in costa rica, but was in california using it | 03:38 |
dsfg | would they have a US or costa rican IP? | 03:38 |
jjohansen | US, | 03:38 |
jjohansen | its not like cell phones | 03:39 |
jjohansen | your "unique" device id would be the ethernet mac | 03:39 |
dsfg | what if he was on a cellphone | 03:39 |
dsfg | in california | 03:39 |
dsfg | using 3g | 03:39 |
dsfg | would he have a US ip or costa rica? | 03:40 |
jjohansen | hehe, that is an interesting problem | 03:40 |
jjohansen | it would depend | 03:40 |
dsfg | on what | 03:40 |
jjohansen | it would depend on how the cellular provided routed cell data traffic, and contracts with other cell carriers | 03:41 |
dsfg | i'm 99% sure he is on a laptop | 03:41 |
dsfg | using wifi | 03:41 |
dsfg | and not a cellphone weith 3g | 03:41 |
dsfg | it's not illegal to find someones IP and trace it to see what country theyre in, is it? | 03:42 |
jjohansen | generally you could accept that it will come from the cell carriers IP pool, so in US us carrier pool, in costa rica - that phone companies pool | 03:42 |
jjohansen | uh no | 03:42 |
dsfg | i feel like i did something wrong | 03:42 |
dsfg | and went snooping! | 03:42 |
jjohansen | well it might be, depends where you are | 03:42 |
dsfg | canada | 03:42 |
jjohansen | no | 03:43 |
dsfg | basically i think this guy is lying about being on vacation in california | 03:43 |
dsfg | cause his IP says he;'s still in costa rica | 03:43 |
jjohansen | geo location is done all the time, for targeting adds or giving you access to servers caching the data closer to you | 03:43 |
jjohansen | uh I am not even going to go there | 03:44 |
dsfg | but i guess i cant be sure | 03:44 |
dsfg | i can be like 99% sure | 03:44 |
jjohansen | it is possible, especially if you are judging from email, as that will likely go out to his isp smtp server which is in costa rica | 03:45 |
dsfg | nope | 03:45 |
dsfg | wasnt email | 03:45 |
jjohansen | I really can't tell you how likely it is, but geo location is right more often than not | 03:45 |
dsfg | okay cool | 03:46 |
dsfg | n ow ive been lied to :( | 03:46 |
dsfg | well ty vm guys | 03:50 |
diwic | anyone still around for ubuntu-audio-dev meeting? | 11:17 |
diwic | sorry wrong channel | 11:18 |
apw | diwic, heh :) | 12:58 |
diwic | apw, yeah I was a little late and was in a hurry :-) | 13:03 |
diwic | apw, I've done worse - the window was not scrolled down completely and so I kept writing and writing wondering why my text didn't show up ;-) | 13:04 |
apw | diwic, heh i've done that too, one does look a bit of a waz | 13:13 |
=== smb` is now known as smb | ||
ari-tczew | hello | 13:41 |
ari-tczew | mjg59: do we really need separate binary package for smartdimmer? | 13:42 |
ari-tczew | can smartdimmer be used with other drivers than nvidia? | 13:42 |
ari-tczew | http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/nvclock/natty/changes?filter_file_id=smartdimmer.install-20090626033400-d3ab2kzykpm31he0-184 | 13:43 |
=== Quintasan_ is now known as Quintasan | ||
=== sconklin-away is now known as sconklin | ||
apw | commit 9bea7f23952d5948f8e5dfdff4de09bb9981fb5f | 14:48 |
apw | Author: Rusty Russell <rusty@rustcorp.com.au> | 14:48 |
apw | Date: Sat Jun 5 11:17:37 2010 -0600 | 14:48 |
apw | module: fix bne2 "gave up waiting for init of module libcrc32c" | 14:48 |
sconklin | apw: https://wiki.ubuntu.com/Kernel/KernelBisection | 15:03 |
apw | sconklin, overall makes sense | 15:29 |
sforshee | apw: bug 215802 | 15:49 |
ubot2 | Launchpad bug 215802 in linux "rtl8187 link quality poor" [Undecided,Confirmed] https://launchpad.net/bugs/215802 | 15:49 |
sforshee | apw: http://launchpadlibrarian.net/58772782/rtl8187.patch | 15:51 |
=== bjf[afk] is now known as bjf | ||
apw | bjf, looks like the CPU count change on maverick has popped the abi on amd64 ... pre-proposed build failed | 16:16 |
bjf | apw, looking | 16:17 |
bjf | apw, there's already an abi bump in that batch, i'll dig into it and work it out though | 16:20 |
bjf | apw, right after the last "start new release" is an "bump abi" | 16:20 |
tgardner | bjf, apw: I already bumped the ABI on Maverick. | 16:21 |
bjf | tgardner, apw, i'll look into the problem | 16:21 |
tgardner | bjf, no, I'm saying that I already fixed the build failure and re-pushed with the ABI bump. I simply rebased it so taht the build is bisectable | 16:22 |
bjf | tgardner, AH! | 16:22 |
bjf | ## | 16:22 |
bjf | ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 16:22 |
bjf | ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting | 16:22 |
bjf | ## | 16:22 |
tgardner | bjf, I'm surprised there isn't an ABI bump required for Lucid. Lemme do a quick build | 16:23 |
apw | tgardner, ahh good | 16:48 |
tgardner | bjf, I'm gonna rebase maverick master-next once again in order t0 catchup with master | 16:48 |
bjf | tgardner, ack | 16:54 |
tgardner | bjf, just a quick check on gitweb to make sure I'm not gonna trash something.... | 16:55 |
bjf | ## | 16:57 |
bjf | ## Kernel team meeting in 3 minutes | 16:57 |
bjf | ## | 16:57 |
JFo | <-lunch | 17:22 |
diwic | apw, this channel works for me | 17:23 |
apw | diwic, so i am not aware of there being a work-item gating someone for this docs | 17:23 |
apw | so where can i find out who is waiting on it | 17:23 |
diwic | apw, that's beyond my knowledge as I'm not really familiar with the work item infrastructure | 17:24 |
apw | diwic, well to be on the release team radar its gonna be in the work items system | 17:25 |
apw | but anyhow, who is waiting on it? | 17:25 |
diwic | apw, well, I'd say alessio / TheMuso | 17:25 |
diwic | apw, for making the lowlatency flavour | 17:25 |
diwic | apw, which, as I understand it, they want to have in universe for Natty | 17:26 |
apw | well i am pretty sure allessio has already made one, so doesn't really need any documentation overall, its unlikely they are blocked | 17:26 |
diwic | apw, are we having information on how to best rebase with the official channels w r t SRU and security? | 17:27 |
apw | i am not sure i was expecting that to be in the documentation anyhow | 17:28 |
apw | rebases are all advertised on release in our repos | 17:28 |
diwic | apw, and I'm not sure alessio's kernel follows all conventions we want in its current state | 17:28 |
apw | diwic, no but last time he dropped out when we tried to help him and it got lost in the noise | 17:29 |
diwic | apw, but a document would help others to help out if one person "drops out" | 17:29 |
apw | yep, and it is on my todo list, but i'd not heard any real consumers so its not been a priority | 17:30 |
=== ogra is now known as Guest34014 | ||
apw | poor Guest34014 | 17:30 |
diwic | apw, ok so my expectations on this document would be instructions for how to get SRU and security updates for a derivative flavour, as well as "convention" instructions | 17:32 |
apw | that can be encapsulated in one line however, "follow updates to master" | 17:33 |
apw | as all cves and sru's go there first | 17:33 |
diwic | apw, so now you've made half the document ;-) | 17:34 |
apw | i guess i am not understadning why this is so hard for people | 17:34 |
diwic | apw, can one get notifications when updates to master occur? | 17:35 |
diwic | apw, or do we have to poll once a day/hour/etc? | 17:35 |
tgardner | bjf, have we formally requested regression testing for kvm on the various releases? | 17:36 |
apw | diwic, there should be emails out to the kernel-team and installer when they occur in general | 17:36 |
bjf | tgardner, i believe it was discussed but not sure we formally requested such testing | 17:37 |
apw | diwic, also they should apper on the per-series changes list i guess | 17:37 |
diwic | apw, ok, so one can listen to them either manually or automatic (the latter preferred) - I'm not saying it's hard, it's just a lot of things to be aware of | 17:37 |
bjf | tgardner, part of the discussion was that QA was using that for testing rather than real HW and we had an problem with that | 17:37 |
apw | bjf, i presume you mean 'just kvm' in that context | 17:38 |
bjf | apw, correct | 17:38 |
apw | diwic, i am not against writing it, its just not at the top of my list. i have a2 to worry about | 17:38 |
apw | diwic, i don't think there is much blocing people without it, so its not obviously a priority | 17:38 |
apw | diwic, i suspect anyone i would want making kernels ought to be up on how the packaging works well enough | 17:39 |
apw | diwic, to figure it out, or we should worry more about other things going wrong. like linux-libc-dev getting wacked | 17:39 |
tgardner | bjf, in this case I'd like to verify that we've not regressed KVM gues support on the host under test. | 17:39 |
bjf | tgardner, sconklin and I will bring it up with QA | 17:40 |
tgardner | bjf, reference CVE-2010-3698 as a basis for your discussion | 17:41 |
ubot2 | tgardner: The KVM implementation in the Linux kernel before 2.6.36 does not properly reload the FS and GS segment registers, which allows host OS users to cause a denial of service (host OS crash) via a KVM_RUN ioctl call in conjunction with a modified Local Descriptor Table (LDT). (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3698) | 17:41 |
diwic | apw, ok. so I'll try to communicate that this document won't be created within the coming weeks and given that, #ubuntu-kernel and the ML would be helpful in general for any specific questions. | 17:41 |
apw | diwic, as you know we are short of bodies right now even for the committed effort | 17:41 |
apw | diwic, seems about right yes | 17:41 |
diwic | apw, ok, thanks. | 17:43 |
diwic | apw, I'll send something out on the ubuntu-studio-devel ML about it | 17:43 |
=== sforshee is now known as sforshee-lunch | ||
=== Guest34014 is now known as ogra_ | ||
=== bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - February-01 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
diwic | how many bits is a pointer in a 32-bit-pae kernel? | 18:30 |
tgardner | diwic, 32 | 18:32 |
diwic | ok, thanks | 18:32 |
diwic | tgardner, so sizeof(buf2 - 8) would evaluate to "4"? | 18:34 |
jjohansen | diwic: no | 18:34 |
jjohansen | sizeof(buf2) - 8 might depending on what buf2 is | 18:35 |
tgardner | sizeof(void *) will evaulate to 4 | 18:35 |
diwic | jjohansen, so I have discovered a bug where it says sizeof(buf2 - 8), it should say "sizeof(buf2) - 8" | 18:36 |
jjohansen | diwic: but you need to be careful with sizeof and structs, as C can pad them and return sizes different than you might expect | 18:36 |
diwic | jjohansen, so the question is what "sizeof(buf2 - 8)" would evaluate to in a 32-bit-pae kernel | 18:36 |
tgardner | diwic, sizeof(buf2 - 8) is definitely a bug | 18:36 |
jjohansen | diwic: ugh, I am surprised that even compiles | 18:37 |
diwic | jjohansen, I'm curious if it could be a security thing or if I should just fix it and send upstream | 18:37 |
diwic | fwiw, buf2 is a char[24] | 18:37 |
jjohansen | diwic: can you point me at the code? | 18:38 |
diwic | jjohansen, sound/pci/hda/hda_eld.c:384 | 18:39 |
jjohansen | diwic: natty? | 18:39 |
tgardner | apw, I pushed CONFIG_NR_CPUS=256 for natty amd64 -generic. Am boot testing on hoover. | 18:39 |
diwic | jjohansen, that line has been in there since 2008 | 18:39 |
diwic | jjohansen, in function hdmi_show_short_audio_desc | 18:40 |
jjohansen | diwic, okay looking | 18:40 |
tgardner | diwic, it doesn't even make sense. | 18:40 |
tgardner | it really should be sizeof(buf2)-8 | 18:41 |
diwic | tgardner, so far we agree :-) | 18:41 |
tgardner | diwic, have you confirmed that it fixes the problem? | 18:41 |
diwic | tgardner, the question is if it could evaluate to something larger than buf2 | 18:41 |
diwic | tgardner, nope, don't have hw | 18:42 |
jjohansen | diwic: I don't see how it has any security concerns | 18:42 |
tgardner | diwic, you could write a short test program to see what it does. | 18:42 |
diwic | jjohansen, good. I'll then just send a patch upstream. | 18:42 |
diwic | tgardner, I did so and it seems to always evaluate to "8" on my amd64 | 18:43 |
diwic | tgardner, so I guess it evaluates to a pointer | 18:43 |
jjohansen | diwic: yep, buf2 - 8 works out as a pointer | 18:43 |
tgardner | diwic, more likely it evaluates to the last constant in the sizeof() expression. | 18:43 |
diwic | tgardner, nope, tried sizeof(buf2-35) which also evaluates to 8 | 18:44 |
tgardner | well, regardless, that code is busticated | 18:44 |
jjohansen | right, its an array - const which is identified as pointer arithmetic, so it returns a pointer to -8 from the start of the array and then takes the sizeof the pointer | 18:45 |
bjf | apw, you reported a bug against the wiki theme, what was the package name that you filed that against ? | 18:49 |
tgardner | diwic, don't forget to Cc: stable@kernel.org on tat patch. | 18:49 |
tgardner | in the commit message, not in email to LKML | 18:50 |
diwic | tgardner, agreed | 18:50 |
=== sforshee-lunch is now known as sforshee | ||
=== sconklin is now known as sconklin-afk | ||
tjaalton | smb: hey, re bug 415353, do you mean that the proposed lucid kernel should have the patch you mentioned? | 19:08 |
ubot2 | Launchpad bug 415353 in linux "karmic/lucid installation slow on "detecting network hardware" with bnx2x" [Medium,Fix released] https://launchpad.net/bugs/415353 | 19:08 |
tjaalton | because it's not any different to the earlier ones | 19:09 |
smb | tjaalton, Hi, well not more differently what you tested last (which is the 90s delay) | 19:10 |
smb | But initially there were like hours delay reported | 19:10 |
tjaalton | the installer probes them twice | 19:10 |
tjaalton | and the timeout seems to be 100s and not 30 like on an installed system | 19:11 |
tjaalton | which is weird.. | 19:11 |
* tgardner --> lunch | 19:11 | |
smb | well the 100s (is near 90) | 19:11 |
smb | which is trying tree times a 30s timeout | 19:11 |
tjaalton | ok | 19:11 |
tjaalton | I'll try the kernel package | 19:11 |
smb | tjaalton, much appreciated | 19:12 |
=== diwic is now known as diwic_afk | ||
tormod | fyi I get warnings about CONFIG_ACPI_PROCFS_POWER when booting the latest .38 mainline snapshot | 19:18 |
=== cmagina is now known as cmagina-shovelin | ||
tjaalton | smb: success! though, there are ugly errors too | 19:22 |
tjaalton | smb: http://users.tkk.fi/~tjaalton/foo/dmesg.txt | 19:24 |
smb | tjaalton, If you place the dmesg into the bug report, I will have a look tomorrow. Possibly the backport needs some tweaking. | 19:24 |
tjaalton | alright, will do | 19:24 |
* smb has moved to the beer part of the evening and should not be trusted anymore. :) | 19:24 | |
* tjaalton will follow shortly | 19:25 | |
smb | tjaalton, but quickly glancing this may tell me that I need to pull in a few more changes from later. I went around some parts which seemed to add a new list of dependency relationships | 19:28 |
tjaalton | cool | 19:29 |
=== yofel_ is now known as yofel | ||
=== diwic_afk is now known as diwic | ||
=== diwic is now known as diwic_afk | ||
tgardner | apw, my emerald ran 3600 seconds of stress on 2.6.38-1 master-next | 19:54 |
=== cmagina-shovelin is now known as cmagina | ||
* jjohansen -> lunch | 20:10 | |
tgardner | zul, do you remember what xen version we used for Hardy? | 20:33 |
zul | tgardner: barely...it might have been 3.4 | 20:34 |
zul | tgardner: gimme a sec and i can give you a better answer | 20:35 |
zul | tgardner: 3.3 | 20:37 |
tgardner | zul, maybe 'UBUNTU: build/custom: Hello Xen 3.0.5' | 20:37 |
zul | tgardner: sounds right | 20:37 |
=== charlie-tca__ is now known as charlie-tca | ||
tgardner | zul, yep, I don't see any major updates after that. mostly small fixes. | 20:38 |
zul | tgardner: yeah it was when i was volunteering | 20:38 |
tgardner | man, that was awhile ago. | 20:39 |
zul | tgardner: it was...i still had hair :) | 20:46 |
JFo | I just love it when the Launchpad server disappears from under a script | 21:24 |
lifeless | what happened? | 21:24 |
bjf | JFo, can you accept nominations ? | 21:26 |
lifeless | JFo: what happened? | 21:26 |
=== diwic_afk is now known as diwic | ||
JFo | bjf, I can | 21:28 |
JFo | lifeless, I had a script running along nicely and then a huge stack trace basically meaning that the server disappeared | 21:28 |
bjf | jfo, please accept all my nominations https://bugs.launchpad.net/ubuntu/+source/linux/+bug/707649 | 21:28 |
ubot2 | Launchpad bug 707649 in linux "CVE-2010-4079" [Undecided,New] | 21:28 |
JFo | We have gotten a lot of help from various people in the #ubuntu-bugs channel. I'd like to thank charlie-tca specifically and several others in there whose nicks escape me at the moment for directing questions about kernel bugs to me. There have also been a ton of requests through irc to look at specific bugs. In those cases, and many like them, I am directing folks to the bug triage pages of our wiki. I hope that some of these folks will become re | 21:29 |
JFo | gular triagers, but that remains to be seen. :) | 21:29 |
lifeless | JFo: I treat such problems as high severity issues | 21:29 |
lifeless | JFo: did you get a OOPS in one of the headers? or could you pastebin the backtrace? | 21:29 |
ekoore | hi to all | 21:30 |
JFo | actually lifeless hang on a sec | 21:30 |
JFo | I may be experiencing connectivity issues | 21:30 |
=== alex_jon1 is now known as alex_joni | ||
ekoore | i have a small problem with the linux kernel in my device | 21:31 |
JFo | bjf, all accepted | 21:31 |
bjf | JFo, your too kind | 21:31 |
JFo | lifeless, I have an install running and I told it to download updates as well. I don't normally | 21:31 |
JFo | :) | 21:31 |
JFo | bjf, it is my pleasure :) | 21:32 |
JFo | lifeless, so I may have accused LP unnecessarily in this case | 21:32 |
ekoore | JFo can you help me? | 21:33 |
lifeless | JFo: when LP goes wrong, please do file a bug (even if its a dupe - that guides heat after all) | 21:33 |
JFo | lifeless, I will indeed | 21:33 |
lifeless | JFo: however there isn't all that much we can do if you fill your net connection :P | 21:33 |
JFo | let me conduct a test in any case and I will let you know the results via bug if necessary | 21:33 |
JFo | lifeless, :-P | 21:33 |
JFo | I wish | 21:33 |
JFo | ekoore, what is the nature of your problem? | 21:34 |
lifeless | JFo: as background, we have 2 ssl front ends, 2 ha proxy load balances, and ~ 20 frontend appservers behind those | 21:34 |
ekoore | is a problemwith an acpi | 21:34 |
lifeless | JFo: so for that stack to just go awol is a Big Fricking Deal | 21:34 |
JFo | lifeless, I can definitely imagine | 21:34 |
lifeless | :) | 21:34 |
* JFo is about to rip his service provider a new one anyway | 21:34 | |
JFo | ekoore, is there a bug open I can look at? | 21:35 |
ekoore | JFo: not, let me explain | 21:36 |
JFo | lifeless, thanks for inquiring. I can imagine you are quite busy constantly | 21:36 |
JFo | :) | 21:36 |
JFo | ekoore, ok | 21:36 |
ekoore | i work in a company: www.ekoore.com | 21:36 |
lifeless | JFo: I'm kept on my toes, yes :) | 21:36 |
JFo | heh | 21:36 |
ekoore | now i have to prepare a new device | 21:36 |
ekoore | multitouch with ubuntu | 21:36 |
JFo | ok | 21:37 |
ekoore | this device have a G-Sensor | 21:37 |
JFo | G-sensor? | 21:37 |
* JFo is unfamiliar | 21:37 | |
ekoore | yes, accelerometr | 21:37 |
bjf | JFo, G-spot sensor | 21:37 |
ekoore | do you know? | 21:37 |
JFo | bjf :) | 21:38 |
JFo | ekoore, I see | 21:38 |
ekoore | sensor of gravitation | 21:38 |
JFo | I am vaguely familiar with those | 21:38 |
ekoore | this sensor cause a problem with acpi | 21:38 |
JFo | I see | 21:39 |
ekoore | when i rotate the tablet, the screen of the tablet power off | 21:39 |
ekoore | i have a solution: | 21:39 |
JFo | rotate as in from landscape to portrait? | 21:39 |
ekoore | this comand: | 21:39 |
ekoore | echo disable > /sys/firmware/acpi/interrupts/gpe11 | 21:40 |
ekoore | i can write this comand in rc.locale file | 21:40 |
ekoore | but it is do only to the end of the boot sequence | 21:41 |
ekoore | is possible disabling this interrupt directly in the device | 21:41 |
ekoore | ? | 21:41 |
ekoore | directly in the kernel? | 21:41 |
ekoore | or to the start of boot sequence? | 21:42 |
ekoore | JFo, do you think that is possible? | 21:43 |
JFo | those are very good questions, but I don't know much about acpi events | 21:43 |
JFo | and the person I would normally ask is away for the day | 21:44 |
JFo | ekoore, do you think you would mind sending the above information to the team mailing list? | 21:45 |
JFo | that way the appropriate parties will see it and provide advice? | 21:45 |
ekoore | sure, this is not a problem | 21:45 |
ekoore | information about the problem? | 21:46 |
ekoore | where i have to write? | 21:48 |
JFo | ekoore, kernel-team@lists.ubuntu.com | 21:49 |
ekoore | and they answare me in email? | 21:50 |
JFo | yes | 21:51 |
ekoore | ok JFo, thank you | 21:56 |
JFo | my pleasure ekoore | 21:57 |
JFo | :) | 21:57 |
ekoore | JFo, do you know other person that can help me? | 21:59 |
ekoore | After that i send the email to the maling list | 21:59 |
JFo | I don't know of anyone who is available in this time zone | 22:00 |
ekoore | if they don't answare me | 22:00 |
JFo | but the people I have in mind will see it on the mailing list | 22:00 |
ekoore | where you come frome? | 22:00 |
JFo | what do you mean? | 22:01 |
ekoore | where do you come from? | 22:01 |
JFo | I am in the US | 22:01 |
ekoore | oh, i am in italy | 22:02 |
JFo | cool | 22:02 |
ekoore | california? | 22:02 |
JFo | no, I am in North Carolina | 22:03 |
ekoore | oh beautifoul | 22:04 |
JFo | yep, it is nice here | 22:04 |
=== cmagina-lunch is now known as cmagina | ||
=== bjf is now known as bjf[afk] |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!