[00:04]  * rtg_ -> EOD
=== optimusprimem is now known as optimus-afk
[05:58] <infinity> apw: Bah.  Headers for manta and mako didn't get flavourized, so they're sharing package namespace.
[05:59] <infinity> apw: Care to fix, lowlatency/ppc style?
[06:00] <infinity> apw: (Also true for grouper, it's just lucky that it has no other 3.1.10 kernels to compete with for namespace)
[08:45]  * apw moans about spinning globes
[09:11]  * RAOF pours apw a steaming hot cup of bees to cheer him up.
[09:12] <apw> RAOF, very thoughtful, interestingly they have been in my house the last couple of days, i should have thought of drinking them
[09:12] <RAOF> They are gloriously spicy!
[09:14] <apw> did you avoid the ubu-flu this time?  seems the .eu contingent has been struck down
[10:39] <zequence> apw: All lowlatencies prepared, including raring (first time doing that one, but the only difference I saw was that the changelog said raring instead of raring-proposed after doing the scripted update, which I suppose is meant to happen).
[10:40] <apw> yep, there is no need for -proposed in any release now, the archive rewrites it for us
[10:53]  * ppisati -> (long) lunch break
=== akashj87_ is now known as akashj87
[11:31] <ignatenkobrain> hi all !
[13:29]  * henrix -> late lunch
=== kentb-out is now known as kentb
[14:28] <sconklin> apw: status on the cve tracker?
[14:30] <apw> sconklin, should be all live and well now
[14:30] <apw> sconklin, it now has the new HWE bits in it etc, and seems to be updating right now
[14:30] <apw> s/right/correctly
[14:31] <sconklin> apw: ack, I'll run the merge in a bit
[14:40] <apw> rtg_, arn't we meant to select the AP with the best signal if there are more than one with the same SSID ?
[14:41] <rtg_> apw, seems like that was the algo that was described to me
[14:41] <rtg_> modulo supported bit rate
[14:41] <rtg_> max bit rate
[14:44] <apw> rtg_, i have sent you my channel dump, it is selecting cell 01 over cell 06
[14:44] <apw> wh
[14:45] <apw> which as far as i can see if about as wrong as it could be
[14:45] <rtg_> apw, max bit rate is 9 v.s. 6
[14:45] <rtg_> doh! nm
[14:46] <rtg_> apw, 01 has a lot higher signal strength
[14:46] <apw> rtg_, how so
[14:46] <apw> the signal levels are in negative units
[14:47] <apw> the signal levels are in negative units
[14:47] <rtg_> -75 is higher then -53. get cking to explain it.
[14:47] <rtg_> or sconklin
[14:47] <apw> it is?
[14:47] <apw> are you sure
[14:47] <rtg_> ('cause I can't remember)
[14:48] <apw> rtg_, this here wifi analyser has bars which are better the higher they are, and the scale is 0dBm at the top and -100dBm at the bottom
[14:48] <sconklin> generally, signal strength is not inverted from the measurements, although it is common for the measurements to be negative if they are less than some standard. Lower is weaker.
[14:48] <apw> rtg_, plus the cell 01 AP is really far away, and 06 is really near
[14:49] <apw> sconklin, so -100 is worse than -50 yes ?
[14:49] <rtg_> ok, perhaps I am misremembering
[14:49] <apw> (these are wifi cell stengths)
[14:50]  * apw contends it is doing something dumb
[14:50] <rtg_> apw, mathieu trudeau was messing with the selection algo. perhaps you should consult him.
[14:51] <apw> rtg_, is that a userspace thing, or a kernel thing
[14:51] <rtg_> apw, supplicant IIRC
[14:51] <apw> ok
[14:52] <apw> i hate networking, it is soooo difficult to get right
[14:57] <apw> hmm it just changed over, now that is odd
[15:01] <henrix> smb: hi! re your "ACK w/whine" :)
[15:01] <smb> henrix, yeees? :)
[15:02] <henrix> smb: i send a single patch when git am succeeds without any output
[15:02] <henrix> smb: whenever there's some warn/... i send different patches for each serie
[15:02] <henrix> smb: even if git am do the right thing
[15:03] <smb> ah ok. probably makes sense then
[15:03] <henrix> smb: i do a cherry-pick, a format-patch and check to wich series it applies cleanly
[15:06] <smb> henrix, I guess I should be looking a bit more carefully at the surroundings if there is multiple "cherry-picks". did not spot anything on those two
[15:07] <henrix> smb: there should be... let me check again
[15:08] <smb> henrix, not sure it matters. Looks like they get applied as we speak
[15:09] <henrix> smb: yeah, they are slightly different. maybe i could just request a cherry-pick for all the relevant series instead, when they are clean cherry-picks
[15:09] <henrix> smb: instead of sending 3 different patches. at least, there will be less noise in the ml
[15:09] <henrix> (says the guy that keeps spamming the list with 3.5.y mails :) )
[15:09] <smb> heh :)
[15:12] <smb> henrix, Maybe it is only me but for now when I see cherry-pick in the patch I assume it is the same "quality" (iow format-patch taken as git am)
[15:14] <henrix> smb: so, what would be your suggestion?  should i replace the 'cherry picked from...' by 'back ported from...' when the patch doesn't match the original commit?
[15:15] <henrix> i'm ok with that
[15:15] <smb> I probably would do that, yeah. And I would use "cherry-picked" and "backported" because I am anal... :-P
[15:17] <henrix> heh, ok. i'll do that then. thanks
[15:52] <rtg_> ogasawara, do you have the HW to repro the bug in bug #1178191 ?
[15:52] <ubot2`> Launchpad bug 1178191 in intel "[Ubuntu13.04 final]S3/S4 automatic resume when connect the USB3.0 hub and storage on SharkBay platforms" [Undecided,New] https://launchpad.net/bugs/1178191
[15:54] <zedtux> Hello everyone. I already spoke in that channel with jpds about my issue https://bugs.launchpad.net/ubuntu/+source/linux/+bug/929715 where I have posted a git repo with an example of code that reproduce the issue. Could someone tell me what is the next step for my issue ?
[15:54] <ubot2`> Launchpad bug 929715 in linux (Ubuntu) "netfilter_ipv4.h:13:47: fatal error: limits.h: No such file or directory" [Medium,Confirmed]
[15:55] <ogasawara> rtg_: I've got the shark bay desktop, but I don't have a usb 3.0 device.  lemme check if I can reproduce without it.
[16:06] <rtg_> zedtux, your include issue is prolly fixed in 3.8 or 3.9 with the transition to uapi. I see that limits.h now lives at include/uapi/linux/limits.h
[16:08] <zedtux> sorry rtg_ what means "prolly" ?
[16:08] <rtg_> zedtux, probably
[16:08] <zedtux> Ha! :D
[16:09] <zedtux> But in my latest comment I say that I tried with kernel version 3.8.0-19 and still have the issue. So let's hope with the 3.9 version.
[16:14] <henrix> zedtux: why are you undef'ing __KERNEL__ in a kernel module? haven't took a look at the details, but i'm pretty sure that's not a good idea
[16:14] <zedtux> henrix, Otherwise I have a compilation issue. Let me find the error message
[16:15] <zedtux> henrix, see my comment: // This is needed in order to have access to NF_IP_PRE_ROUTING and NF_IP_POST_ROUTING
[16:17] <zedtux> Also often I saw this (like in this link: http://stackoverflow.com/questions/12073963/how-to-access-data-payload-from-tcphdr-sk-buff-struct-on-debian-64-bits)
[16:17] <zedtux> henrix, (http://www.lainoox.com/tag/netfilter-firewall/)
[16:21] <henrix> zedtux: right, i'm not familiar with that code. it doesn't seem to make sense to me, but you may be right
[16:22] <henrix> zedtux: however, if i grep the kernel code for NF_IP_PRE_ROUTING i find exactly one hit -- and its meant to be used in user space only
[16:22] <zedtux> henrix, I understand no worry. You're right it's strange...
[16:22] <henrix> zedtux: so, you may be using the wrong define. but again, i may be wrong
[16:23] <zedtux> henrix, ha.. that could explain the strange undef and compilation issue..
[16:27] <zedtux> See u and thank you rtg_ and henrix
[16:39] <ogasawara> rtg_: I'm unable to reproduce with a non usb 3.0 device.  I'll see about picking one up later and re-testing.
[16:40] <rtg_> ogasawara, ack
[18:38] <sconklin> apw: here?
[19:45] <apw> sconklin, yo
[19:46] <sconklin> heya
[19:46] <apw> s'up
[19:47] <sconklin> question: does the cve tracking magic update by using upstream sha1s in commits to our trees, even in the absence of a CVE field in the commit?
[19:47] <apw> yes it only uses the sha1s
[19:47] <apw> the cve information is not looked at at all
[19:47] <sconklin> ok. does anything in our process look at the CVE field?
[19:47] <apw> this means that stable updates triggre cve closure correctly
[19:48] <apw> i think launchpad does a little to tie an upload to a CVE
[19:48] <sconklin> yes, I agree that this is the way it should work (not that it matters) :-)
[19:48] <sconklin> ok, that was all
[19:48] <sconklin> thanks
[19:48] <apw> np night
=== smb` is now known as smb
[21:57] <infinity> rtg_: https://launchpad.net/ubuntu/+source/linux-meta-lts-raring looks more sensible now.
[21:57] <rtg_> infinity, ack
[21:58] <infinity> (This is what happens when SRUs don't go through the usual tracking process, I let it slip through)
[21:58] <infinity> Luckily, recovering dead packages is totally doable now.
=== kentb is now known as kentb-out
[22:02] <rtg_> infinity, I don't think this was supposed to be an SRU, was it ? It was an initial upload.
[22:02] <infinity> rtg_: Well, sure, but an initial upload to proposed, not release, so still SRUish in the process.
[22:02] <infinity> rtg_: (Could have skipped a bunch of verification steps and such, sure)
[22:03] <rtg_> hmm
[22:03] <infinity> Mostly, it's just that without the tracking bug to remind me to copy everything that related to linux-foo, I forgot, and then linux-meta got overridden with the new one from the PPA being copied.  Not world-ending, and mostly my fault.
[22:03] <infinity> Just saying a tracking bug would have held my hand. :)
[22:04] <rtg_> infinity, ok, I'll make sure to get it right when  upload saucy LTS et al