| === ohsix_ is now known as ohsix | ||
| === emma_ is now known as em | ||
| * apw yawns a 2014 yawn | 08:55 | |
| === sivatharman__ is now known as psivaa | ||
| === lag` is now known as lag | ||
| === rsalveti_ is now known as rsalveti | ||
| apw | rtg, so i guess we just need a quick review of the current state of the dkms packages and we ought to be good to go to the archive ? | 13:37 |
|---|---|---|
| rtg | apw, yep, I think it should be pretty close. I'd like to do some commit log squashing, but that could wait .... | 13:38 |
| rtg | apw, I'll put -unstable back on tangerine today to see how it does | 13:38 |
| apw | rtg, i don't think i am in a rush or anything, so feel free to squash away | 13:38 |
| rtg | apw, gotta grind through a zillion emails first | 13:39 |
| apw | is it jibel who does the dkms runs for us ? | 13:39 |
| rtg | apw, think so | 13:39 |
| eagles0513875 | hey guys how is everyone | 13:41 |
| * apw is larded out :) | 13:41 | |
| eagles0513875 | I am encountering a bug that has a patch which needs to be applied to the kernel, and this has yet to be applied and has been sitting with the patch to be applied to the kernel since 2012 for precise. I am also seeing this issue in saucy as well what is the procedure to get this patch applied and pushed out as an SRU update for the kernel | 13:42 |
| eagles0513875 | the bug is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/967399 | 13:42 |
| ubot2 | Launchpad bug 967399 in linux (Ubuntu) "[11.10] Elantech trackpoint does not work Lenovo " [High,In progress] | 13:42 |
| apw | eagles0513875, well teh patch referenced there never seems to have made it into the mainline kernel | 13:46 |
| eagles0513875 | apw: even though its not in mainline yet can a request be made to have it in ubuntu until its upstreamed | 13:46 |
| apw | cirtainly not in that form anyhow. does a later kernel for work that device? ie. is it unfixed in the latest kernels which seem to have a heap of patches for "newer hardware support" up to and including v7 | 13:48 |
| apw | (first half there is in response to your previous question) | 13:48 |
| apw | the patch there looks very preliminary, and therefore we would rather see consensus upstream on it (assuming it remains unfixed) before taking osmething which will cause us pain later | 13:49 |
| apw | it is not clear for instance it is tied to the right devices so might leak to other h/w etc | 13:49 |
| apw | eagles0513875, so my first request would be for testing on trusty with the latest 3.13 kernel applied | 13:50 |
| apw | eagles0513875, it would also be helpful to follow up to that email thread which seems to have only the patch and ask what happened to it | 13:53 |
| eagles0513875 | I will do so | 13:53 |
| eagles0513875 | apw: is there a backport version for 13.10 that i can test with? | 13:54 |
| apw | eagles0513875, https://launchpad.net/~canonical-kernel-team/+archive/ppa/+sourcepub/3765254/+listing-archive-extra has links to i386 and amd64 kernel packages | 13:55 |
| apw | for the very latest 3.13 kernel, less than an hour old | 13:55 |
| apw | you'll likely want linux-image and linux-image-extra in either case | 13:56 |
| eagles0513875 | apw: i was going to run an update and let apt pull the latest version | 13:58 |
| apw | 3.13 isn't in archive as yet, will be this week most likely, but not yet | 14:00 |
| eagles0513875 | apw: O_o | 14:00 |
| eagles0513875 | https://launchpad.net/~canonical-kernel-team/+archive/ppa | 14:01 |
| eagles0513875 | if you look at the teams ppa it seems to be there? | 14:01 |
| apw | yes, only in trusty of course | 14:01 |
| apw | which isn't 13.10 | 14:01 |
| eagles0513875 | oh ok | 14:01 |
| sforshee | rtg: Intel has new wireless firmware that they're recommending we pick up for 3.10+ | 14:31 |
| sforshee | http://www.spinics.net/lists/linux-wireless/msg116518.html | 14:31 |
| rtg | sforshee, ack | 14:31 |
| rtg | sforshee, hmm, best wait until we inflict 3.13 on the archive | 14:32 |
| rtg | unless they are new files | 14:33 |
| sforshee | rtg: oops, that was the wrong thread | 14:34 |
| apw | "Anyone who wants to use this firmware must have 3.13 at least. | 14:34 |
| apw | " | 14:34 |
| apw | ? | 14:34 |
| sforshee | yeah, I was talking about something different | 14:34 |
| rtg | apw, generally upates have new files so there is no conflict with older kernels | 14:34 |
| sforshee | he just used the same subject for both threads :-/ | 14:34 |
| apw | though it is a new version number anyhow so it hsould be safe | 14:34 |
| apw | right, so the warnign is specious at best, sigh | 14:35 |
| rtg | yep | 14:35 |
| rtg | apw, I'll pick 'em up as soon as I can get tangerine back to life | 14:35 |
| apw | oh dear, didn't boot ? | 14:35 |
| rtg | never does | 14:35 |
| sforshee | rtg: http://www.spinics.net/lists/linux-wireless/msg116120.html is what I meant | 14:35 |
| apw | man "fixes a few problems people have been reporting" well shit, tell us already | 14:36 |
| rtg | especially the PSP issues that sforshee has pursued | 14:37 |
| sforshee | the PS problems are on broadcom, intel is fine | 14:37 |
| rtg | sforshee, ah, I thought they were kind of generic | 14:38 |
| sforshee | I'm pretty sure the firmware is supposed to fix problems where the connection dies and a bunch of firmware error messages get spewed to dmesg | 14:39 |
| apw | yeah, shame they don't bother to list them | 14:39 |
| sforshee | yeah, I can bug him for specifics if needed | 14:40 |
| apw | general whine about him not doing so than caring for the specifics | 14:46 |
| rtg | sforshee, Uploading linux-firmware_1.118.dsc: done. | 15:02 |
| sforshee | rtg: ta | 15:03 |
| rtg | sforshee, I'll add the new files to the precise package as well | 15:03 |
| === dannf` is now known as dannf | ||
| caribou | happy new year to anyone who cares about the Ubuntu kernel! | 15:45 |
| caribou | apw: I'm testing your instructions to boot arm64 with foundation mode | 15:45 |
| caribou | apw: and found a slight issue with your conversion script | 15:45 |
| apw | caribou, ok ... whats up it? | 15:49 |
| caribou | apw: well,call it "la faute au français", but when doing your script with a system localized in french, it fails to do the "mkfs -t ext4" | 15:49 |
| caribou | apw: you do "echo y | mkfs" but since it expect (o/n) in french, it defaults to not run mkfs | 15:50 |
| apw | does it work if we just do like "LANG=C" at the top of the script | 15:50 |
| caribou | apw: yep, that's what I used as a workaround | 15:50 |
| apw | ok great | 15:50 |
| caribou | apw: aside from that, works fine for me | 15:51 |
| caribou | apw: I was hoping to use that to do test builds of arm64 packages | 15:51 |
| apw | caribou, great, i have updated the version on people i hope to have that hack in it :) thanks for the testing | 15:52 |
| caribou | apw: np, happy to help | 15:52 |
| === ricmm is now known as ricmm|sick | ||
| apw | rtg, we seem to have a 3.12.0-8 in our repo but not in the archive, is that deliberate? | 15:56 |
| rtg | apw, yeah, I did it over the holidays but never uploaded. we should dpo that today. | 15:57 |
| rtg | apw, I can take care of it. | 15:57 |
| apw | sorry just lost a nic in my firewall ... some usb replugging and it is back | 16:05 |
| apw | rtg, if you want me to do it, yell, else great | 16:05 |
| rtg | apw, just uploaded it.... | 16:06 |
| apw | cool | 16:07 |
| * rtg -> lunch | 18:36 | |
| davmor2 | hey guys this just got assigned over to you from network-manager. is there any other info you need to process it further? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1265564 | 19:31 |
| ubot2 | Launchpad bug 1265564 in linux (Ubuntu) "Regression: Maguro network-manager disconnects from wifi ap" [Medium,Incomplete] | 19:31 |
| rtg | davmor2, unless someone in the community cares, the odds of us having time to look at it are pretty small. | 19:36 |
| davmor2 | rtg: Maguro is the Samgung Galaxy Nexus that we support for Ubuntu Touch | 19:37 |
| rtg | davmor2, I thought that device has been de-prioritized for trusty ? Was the list of devices ever finalized ? | 19:39 |
| davmor2 | rtg: not yet | 19:39 |
| davmor2 | rtg: hence it is still my test device | 19:39 |
| rtg | davmor2, does loss of wifi connection happen frequently ? And do you know for sure that it is a regression ? | 19:40 |
| davmor2 | rtg: It happens if you leave the phone to sleep for a lengthy period, so for example while on holiday it was down stairs I was upstairs sorting things out for most of the day, go down and it had disconnected. Only happen when the phone is sleeping though, when it's active it doesn't shut off wifi | 19:43 |
| davmor2 | and It didn't happen prior to about the weekend so about R100 for trusty | 19:43 |
| rtg | davmor2, well, that almost seems like expected behavior. sforshee ^^ would that have something to do with powerd ? | 19:44 |
| davmor2 | rtg: shutting down seems good as long as it comes back up after, instead you have to manually select the wifi ap again | 19:45 |
| rtg | davmor2, oh, I understand what you are saying. | 19:45 |
| sforshee | rtg: powerd doesn't control anything related to wifi, other than initiating suspend | 19:47 |
| sforshee | though last I knew nm didn't have any smarts to keep the connection alive during suspend | 19:48 |
| rtg | davmor2, the Maguro kernel has not been updated since Oct 7 | 19:48 |
| sforshee | maybe it's happening as a result of inaction, i.e. nm doesn't take down the wifi connection | 19:48 |
| sforshee | and the hardware might be choosing to disconnect after some time | 19:49 |
| rtg | right | 19:49 |
| davmor2 | cyphermox: ^ any chance you can elaberate on your findings? | 19:49 |
| cyphermox | well, it's all there | 19:50 |
| cyphermox | NM isn't causing the device to disconnect, the driver is, somehow | 19:50 |
| cyphermox | it might well be related to wpasupplicant trying to do a new activation, but I don't know | 19:51 |
| sforshee | cyphermox: it's a fullmac device, so more likely the firmware is causing it to disconnect | 19:51 |
| cyphermox | the firmware then :) | 19:51 |
| rtg | cyphermox, have either of those packages changed recently ? | 19:51 |
| cyphermox | nope, not in trusty I think | 19:51 |
| cyphermox | or anyway, not in the past month | 19:51 |
| sforshee | cyphermox: usually if you wanted to keep the connection alive during suspend you'd enable wowlan | 19:52 |
| sforshee | if you're not doing anything special, maybe the firmware decides that the host has gone unresponsive and initiates a disconnection | 19:53 |
| rtg | sforshee, actually, I think davmor2 would just like the device to reconnect on resume. | 19:53 |
| sforshee | rtg: right, I'm getting there ;-) | 19:53 |
| sforshee | so if the firmware disconnects but the host isn't awake to get notified, it might not know that it ever happened | 19:53 |
| sforshee | so maybe something in the stack is just assuming that it's still connected | 19:54 |
| sforshee | just taking some wild guesses :-) | 19:54 |
| davmor2 | rtg, sforshee, cyphermox: it might be that the underlying issue has been there for a while but I'm in QA and work with the phone on and off all day so the device doesn't sleep long enough to die | 19:55 |
| davmor2 | I've only seen it recently while we were on break | 19:56 |
| rtg | davmor2, it may be a function of your AP and how long it waits before initiating a disconnect. | 19:56 |
| cyphermox | well if it's the case perhaps I'll need to spend some more time looking at google's changes to wpa and see if they do anything special with wowlan | 19:57 |
| cyphermox | not going to do that until the sprint I guess, though | 19:57 |
| sforshee | I seriously doubt that they're just leaving the connection active | 19:57 |
| sforshee | they'd have to be setting it up to wake up the cpu whenever something of interest came across | 19:58 |
| cyphermox | there were some changes in their code, it's just a matter or looking at it again to see if now there's something of interest | 19:58 |
| davmor2 | rtg: my tablet always has a connection nexus 7 with ubuntu touch and motorola Xoom on android | 19:58 |
| cyphermox | while you're there, do we have PN544_NFC enabled in the touch kernel? | 19:59 |
| sforshee | cyphermox: also note that powerd is just going to resuspend after the wakeup event is cleared if not told to do otherwise | 19:59 |
| cyphermox | ok | 19:59 |
| rtg | cyphermox, PN544_NFC is not enabled for Maguro | 20:00 |
| cyphermox | ok | 20:01 |
| === cmagina_ is now known as cmagina | ||
| * rtg -> EOD | 21:11 | |
| === kentb is now known as kentb-away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!