| * rtg_ -> EOD | 00:04 | |
| === optimusprimem is now known as optimus-afk | ||
| infinity | apw: Bah. Headers for manta and mako didn't get flavourized, so they're sharing package namespace. | 05:58 |
|---|---|---|
| infinity | apw: Care to fix, lowlatency/ppc style? | 05:59 |
| infinity | apw: (Also true for grouper, it's just lucky that it has no other 3.1.10 kernels to compete with for namespace) | 06:00 |
| * apw moans about spinning globes | 08:45 | |
| * RAOF pours apw a steaming hot cup of bees to cheer him up. | 09:11 | |
| 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:12 |
| apw | did you avoid the ubu-flu this time? seems the .eu contingent has been struck down | 09:14 |
| 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:39 |
| apw | yep, there is no need for -proposed in any release now, the archive rewrites it for us | 10:40 |
| * ppisati -> (long) lunch break | 10:53 | |
| === akashj87_ is now known as akashj87 | ||
| ignatenkobrain | hi all ! | 11:31 |
| * henrix -> late lunch | 13:29 | |
| === kentb-out is now known as kentb | ||
| sconklin | apw: status on the cve tracker? | 14:28 |
| 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:30 |
| sconklin | apw: ack, I'll run the merge in a bit | 14:31 |
| 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:40 |
| 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:41 |
| apw | rtg_, i have sent you my channel dump, it is selecting cell 01 over cell 06 | 14:44 |
| apw | wh | 14:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| * 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:50 |
| apw | rtg_, is that a userspace thing, or a kernel thing | 14:51 |
| rtg_ | apw, supplicant IIRC | 14:51 |
| apw | ok | 14:51 |
| apw | i hate networking, it is soooo difficult to get right | 14:52 |
| apw | hmm it just changed over, now that is odd | 14:57 |
| henrix | smb: hi! re your "ACK w/whine" :) | 15:01 |
| smb | henrix, yeees? :) | 15:01 |
| 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:02 |
| 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:03 |
| 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:06 |
| henrix | smb: there should be... let me check again | 15:07 |
| smb | henrix, not sure it matters. Looks like they get applied as we speak | 15:08 |
| 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:09 |
| 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:12 |
| 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:14 |
| 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:15 |
| henrix | heh, ok. i'll do that then. thanks | 15:17 |
| 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:52 |
| 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:54 |
| 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. | 15:55 |
| 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:06 |
| zedtux | sorry rtg_ what means "prolly" ? | 16:08 |
| rtg_ | zedtux, probably | 16:08 |
| zedtux | Ha! :D | 16:08 |
| 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:09 |
| 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:14 |
| zedtux | henrix, see my comment: // This is needed in order to have access to NF_IP_PRE_ROUTING and NF_IP_POST_ROUTING | 16:15 |
| 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:17 |
| 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:21 |
| 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:22 |
| zedtux | henrix, ha.. that could explain the strange undef and compilation issue.. | 16:23 |
| zedtux | See u and thank you rtg_ and henrix | 16:27 |
| 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:39 |
| rtg_ | ogasawara, ack | 16:40 |
| sconklin | apw: here? | 18:38 |
| apw | sconklin, yo | 19:45 |
| sconklin | heya | 19:46 |
| apw | s'up | 19:46 |
| 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:47 |
| 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 | 19:48 |
| === smb` is now known as smb | ||
| infinity | rtg_: https://launchpad.net/ubuntu/+source/linux-meta-lts-raring looks more sensible now. | 21:57 |
| rtg_ | infinity, ack | 21:57 |
| 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. | 21:58 |
| === kentb is now known as kentb-out | ||
| 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:02 |
| 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:03 |
| rtg_ | infinity, ok, I'll make sure to get it right when upload saucy LTS et al | 22:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!