[00:56] <neur0n> hello?
[03:27] <dsfg> can anyone answer a computery question
[03:29] <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:31] <virtuald> not reliable at all since you can use a proxy or other form of tunnel, but i think it's usually right
[03:32] <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:33] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <dsfg> okay cool
[03:46] <dsfg> n ow ive been lied to :(
[03:50] <dsfg> well ty vm guys
[11:17] <diwic> anyone still around for ubuntu-audio-dev meeting?
[11:18] <diwic> sorry wrong channel
[12:58] <apw> diwic, heh :)
[13:03] <diwic> apw, yeah I was a little late and was in a hurry :-)
[13:04] <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:13] <apw> diwic, heh i've done that too, one does look a bit of a waz 
[13:41] <ari-tczew> hello
[13:42] <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:43] <ari-tczew> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/nvclock/natty/changes?filter_file_id=smartdimmer.install-20090626033400-d3ab2kzykpm31he0-184
[14:48] <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"
[15:03] <sconklin> apw:   https://wiki.ubuntu.com/Kernel/KernelBisection
[15:29] <apw> sconklin, overall makes sense
[15:49] <sforshee> apw: bug 215802
[15:49] <ubot2> Launchpad bug 215802 in linux "rtl8187 link quality poor" [Undecided,Confirmed] https://launchpad.net/bugs/215802
[15:51] <sforshee> apw: http://launchpadlibrarian.net/58772782/rtl8187.patch
[16:16] <apw> bjf, looks like the CPU count change on maverick has popped the abi on amd64 ... pre-proposed build failed
[16:17] <bjf> apw, looking
[16:20] <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:21] <tgardner> bjf, apw: I already bumped the ABI on Maverick.
[16:21] <bjf> tgardner, apw, i'll look into the problem
[16:22] <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:23] <tgardner> bjf, I'm surprised there isn't an ABI bump required for Lucid. Lemme do a quick build
[16:48] <apw> tgardner, ahh good
[16:48] <tgardner> bjf, I'm gonna rebase maverick master-next once again in order t0 catchup with master
[16:54] <bjf> tgardner, ack
[16:55] <tgardner> bjf, just a quick check on gitweb to make sure I'm not gonna trash something....
[16:57] <bjf> ##
[16:57] <bjf> ## Kernel team meeting in 3 minutes
[16:57] <bjf> ##
[17:22] <JFo> <-lunch
[17:23] <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:24] <diwic> apw, that's beyond my knowledge as I'm not really familiar with the work item infrastructure
[17:25] <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:26] <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:27] <diwic> apw, are we having information on how to best rebase with the official channels w r t SRU and security?
[17:28] <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:29] <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:30] <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] <apw> poor Guest34014 
[17:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <bjf> tgardner, sconklin and I will bring it up with QA
[17:41] <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:43] <diwic> apw, ok, thanks.
[17:43] <diwic> apw, I'll send something out on the ubuntu-studio-devel ML about it
[18:30] <diwic> how many bits is a pointer in a 32-bit-pae kernel?
[18:32] <tgardner> diwic, 32
[18:32] <diwic> ok, thanks
[18:34] <diwic> tgardner, so sizeof(buf2 - 8) would evaluate to "4"?
[18:34] <jjohansen> diwic: no
[18:35] <jjohansen> sizeof(buf2) - 8 might depending on what buf2 is
[18:35] <tgardner> sizeof(void *) will evaulate to 4
[18:36] <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:37] <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:38] <jjohansen> diwic: can you point me at the code?
[18:39] <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:40] <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:41] <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:42] <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:43] <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:44] <diwic> tgardner, nope, tried sizeof(buf2-35) which also evaluates to 8
[18:44] <tgardner> well, regardless, that code is busticated
[18:45] <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:49] <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:50] <tgardner> in the commit message, not in email to LKML
[18:50] <diwic> tgardner, agreed
[19:08] <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:09] <tjaalton> because it's not any different to the earlier ones
[19:10] <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:11] <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:12] <smb> tjaalton, much appreciated
[19:18] <tormod> fyi I get warnings about CONFIG_ACPI_PROCFS_POWER when booting the latest .38 mainline snapshot
[19:22] <tjaalton> smb: success! though, there are ugly errors too
[19:24] <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:25]  * tjaalton will follow shortly
[19:28] <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:29] <tjaalton> cool
[19:54] <tgardner> apw, my emerald ran 3600 seconds of stress on 2.6.38-1 master-next
[20:10]  * jjohansen -> lunch
[20:33] <tgardner> zul, do you remember what xen version we used for Hardy?
[20:34] <zul> tgardner: barely...it might have been 3.4
[20:35] <zul> tgardner: gimme a sec and i can give you a better answer
[20:37] <zul> tgardner: 3.3
[20:37] <tgardner> zul, maybe 'UBUNTU: build/custom: Hello Xen 3.0.5'
[20:37] <zul> tgardner: sounds right
[20:38] <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:39] <tgardner> man, that was awhile ago.
[20:46] <zul> tgardner: it was...i still had hair :)
[21:24] <JFo> I just love it when the Launchpad server disappears from under a script 
[21:24] <lifeless> what happened?
[21:26] <bjf> JFo, can you accept nominations ?
[21:26] <lifeless> JFo: what happened?
[21:28] <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:29] <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:30] <ekoore> hi to all
[21:30] <JFo> actually lifeless hang on a sec
[21:30] <JFo> I may be experiencing connectivity issues
[21:31] <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:32] <JFo> bjf, it is my pleasure :)
[21:32] <JFo> lifeless, so I may have accused LP unnecessarily in this case
[21:33] <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:34] <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:35] <JFo> ekoore, is there a bug open I can look at?
[21:36] <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:37] <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:38] <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:39] <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:40] <ekoore> echo disable > /sys/firmware/acpi/interrupts/gpe11
[21:40] <ekoore> i can write this comand in rc.locale file
[21:41] <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:42] <ekoore> or to the start of boot sequence?
[21:43] <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:44] <JFo> and the person I would normally ask is away for the day
[21:45] <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:46] <ekoore> information about the problem?
[21:48] <ekoore> where i have to write?
[21:49] <JFo> ekoore, kernel-team@lists.ubuntu.com
[21:50] <ekoore> and they answare me in email? 
[21:51] <JFo> yes
[21:56] <ekoore> ok JFo, thank you
[21:57] <JFo> my pleasure ekoore 
[21:57] <JFo> :)
[21:59] <ekoore> JFo, do you know other person that can help me?
[21:59] <ekoore> After that i send the email to the maling list
[22:00] <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:01] <JFo> what do you mean?
[22:01] <ekoore> where do you come from?
[22:01] <JFo> I am in the US
[22:02] <ekoore> oh, i am in italy
[22:02] <JFo> cool
[22:02] <ekoore> california?
[22:03] <JFo> no, I am in North Carolina
[22:04] <ekoore> oh beautifoul
[22:04] <JFo> yep, it is nice here