/srv/irclogs.ubuntu.com/2013/10/08/#ubuntu-kernel.txt

=== rbasak_ is now known as rbasak
=== fmasi_afk is now known as fmasi
apw /b infinity 08:35
* apw yawns08:35
ckingmorning apw08:42
xnoxapw: do you know when the next goldfish upload will be made with the compiler switch? does it have to wait on rtg?09:49
apwxnox, it does not have to wait on rtg no, if you are happy it fixes whatever was broke09:51
apwxnox, you are likely the only one using it :09:51
apw:)09:51
xnoxapw: can you please upload it, for me? =)09:52
apwxnox, will look into it indeed09:52
xnoxapw: thanks a lot!09:52
=== davmor2_ is now known as davmor2
apwxnox, can you do a quick test on: http://people.canonical.com/~apw/goldfish-saucy/10:54
apwand make sure they do what you need, if so i can get it uploaded10:54
xnoxapw: ok, give me a few minutes.10:55
apwxnox, np10:55
apwxnox, is it possible that kernel might have some odd behaviour in the sense it carries some aa fixes, which may interact badly if the userspace is not already in your image11:20
xnoxapw: i have most up-todate userspace (saucy rootfs tarball as running on ubuntu touch / all other ports)11:22
xnoxapw: and it's our initramfs, booting ubuntu direct.11:22
xnoxapw: everything looks good =)11:23
xnoxapw: note that I only tried armhf, no support for i386 yet.11:24
apwxnox, ok fine11:24
=== fmasi is now known as fmasi_afk
=== yofel_ is now known as yofel
* henrix -> lunch13:09
=== fmasi_afk is now known as fmasi
apwrtg, yo, i was just about to upload the goldfish kernel to fix this compiler issue, any objections13:47
apwrtg, alfo fyi, the touch kernels are all sitting in the ckt ppa ready for publishing13:47
rtgapw, rock and roll assuming xnox still likes it.13:47
apwxnox, is very happy13:47
xnox=)13:47
rtgcool13:47
apwrtg, ok linux-goldfish is also in ckt as it also ought to wait on the userspace changes to preceed it14:31
apwrtg, we should also decide if we are going to upload the tip of master-next in step, which i have not yet done14:32
rtgapw, right. in fact I was just reading that bug report from jdstrand14:32
apwits alll a bit of a nightmare getting thigs in order14:32
rtgapw, hopefully userspace will all be sorted by tomorrow ?14:33
apwrtg, i am hoping today your time as it were14:41
apwas the kernels are already built generally that will speed up our bit14:41
rtgapw, well, looking at the last comment it appears that jdstrand switched it back to 'in-progress'14:41
apwthere is an issue remaining which is kernel related ultimatly that jjohansen does not intend to fix but to work around in userspace14:42
apwbut i will double check14:42
jsalisbury**15:02
jsalisbury** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting15:02
jsalisbury**15:02
xnoxapw: rtg: what's the bug number / reference for these upload?15:22
xnox*uploads15:22
apwxnox, for the aa3 uploads ?15:24
xnoxapw: yeah, i guess it's bug #1208988 ?15:24
ubot2`Launchpad bug 1208988 in apparmor-easyprof-ubuntu (Ubuntu Saucy) "AppArmor no longer mediates access to path-based AF_UNIX socket files" [Critical,In progress] https://launchpad.net/bugs/120898815:24
apwxnox, yes that is the umbrella15:25
xnoxapw: rtg: can you like just shove the linux-goldfish through, since it really can't regress since emulator is still not working =)15:33
xnoxapw: rtg: it's unseeded so it will even get an auto-accept through the unapproved.15:34
rtgxnox, its ready to be pocket copied. are you sure the apparmor mess won't nail you ?15:34
xnoxrtg: nope, i have apparmor disabled tbh at the moment.15:34
rtgapw ^^15:34
xnoxapw: rtg: i'm nowhere near to care about apparmor yet, I'm yet to see a display output from the emulator15:35
=== fmasi is now known as fmasi_afk
=== fmasi_afk is now known as fmasi
xnoxrtg: apw: thanks a lot.15:52
rtgxnox, apw did all the heavy lifting15:52
apwxnox, just got accepted, should be in the archive in about 10m15:53
slangasek\o/16:02
ricotzrtg, hi :), is it known that the arch-all header packages of the recent mainline kernel builds are missing?16:16
rtgricotz, it is known16:16
ricotzrtg, ok, thanks16:16
rtgricotz, a fix has been applied, builds are in progress. so says apw.16:17
ricotzgreat! :)16:17
apwindeed, the ones i know of with missing headers are re-queued16:18
=== rtg is now known as rtg-afk
=== rtg-afk is now known as rtg
=== JanC_ is now known as JanC
jsalisbury##16:56
jsalisbury## Kernel team meeting in 5 minutes16:56
jsalisbury##16:56
=== psivaa is now known as psivaa-afk
=== rtg is now known as rtg-afk
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues October 15th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
=== psivaa-afk is now known as psivaa
=== fmasi is now known as fmasi_afk
=== rtg-afk is now known as rtg
rtgarges, so whats the story on this readline patch ? are you getting any upstream traction ?18:27
argesrtg: no i haven't done anything upstream, mostly just testing on my end18:28
rtgarges, were you thinking that we might carry it forever ?18:29
argesrtg: No. I was planning on replying to that thread and saying that we've tested it and havent had issues. However I think getting the analysis done that the maintainer wanted would make it acceptible for him18:30
rtgarges, are you referring to https://lkml.org/lkml/2013/9/11/825 ?18:31
argesHe's worried there may be a possible reader deadlock. I looked over it and tried to trace through the code myself, but it will take a bit more time for me to have a reasonable grasp on tty. I'd also like to figure out a good test case to test potential racey issue as well18:31
argesYes18:31
argesrtg: so if we'd like to be cautious, i think we can wait on the SRU. From my own testing and the fact we haven't hit any regressions with this in Saucy yet, it seems like we are in good shape. but I'd really like to make sure everybody is confortable with this patch18:33
rtgok, seems like there has been reasonable testing with saucy.18:33
rtgarges, unless this patch is the root of many suspend/resume issues :)18:33
argesI was sitting here with my saucy laptop pasting >4KB into a terminal over and over and over trying to get it to fail and so far it hasn't18:34
argesrtg: which bugs? I'd be happy to test with and without this patch.18:34
rtgarges, with the patch I presume18:34
argesrtg: yup18:34
rtgarges, just kidding about the s/r issue.18:34
argesoh ok : ) had me worried...18:34
rtgarges, most of them have s/r problems even on mainline18:35
rtgif not, jsalisbury would be all over me18:35
rtgjdstrand, does apparmor-easyprof-ubuntu (1.0.36) satisfy userspace requirements for the set of kernel patches from jjohansen ?18:40
jdstrandrtg: no. need apparmor userspace18:40
jdstrandrtg: that is ready and being discussed in #ubuntu-ci-eng18:40
rtgjdstrand, ok, lemme know when all is ready.18:40
rtgwe've got the kernels staged in a PPA18:40
jdstrandrtg (and apw): fyi, apparmor was accepted and making its way to proposed. note, lool mentioned something about waiting on the kernel. please coordinate with him18:59
rtgjdstrand, ack19:00
loolrtg: hey19:00
loolrtg: trying to land mir tonight, switching kernels at the same time is a bit much, so I was thinking tomorrow would be a better time19:00
rtglool, they are all ready staged in the kernel ckt PPA, so you can get an AA to copy them at your leisure19:00
loolrtg: it's a two steps thing IIUC: kernels are uploaded and built, then we rebuild "android" package that generates all the boot images from them19:00
jdstrandlool: I would think the non-touch kernels could go now though19:01
loolrtg: ok; didn't know the kernels were ppa-copied into the archive too  :-)19:01
looljdstrand: oh yes19:01
loolrtg: I dont want to block anything non-touch though19:01
jdstrandbut I am not pushing for that. whatever is easier for people19:01
loolrtg: jdstrand has uploaded all apparmor bits now (in -proposed)19:01
rtglool, no problem. I'm about to fire up the distro kernel as soon as I see apparmor roll into release19:02
loolrtg: outside of apparmor AF_UNIX, is anything else staged in the touch kernels?19:03
rtglool, nope, apw and I kept changes to a minimum.19:03
loolrtg: Ok; thanks19:04
loolrtg: added to landing plan19:04
apwlool, rtg actually there is also ogras ureadahead patch in there in two of them19:04
rtgah, forgot about the trace patch19:05
loolapw: ah right, he mentioned that19:06
loolthat's ok; noted down though19:06
rtglool, cking has tested all touch kernel variants (I think)19:06
loolrtg: oh wow, cool19:07
loolrtg: boot tested?19:07
loolmight be worth testing with Mir on mako + maguro19:07
loolcking: ^19:07
apwlool, confirmed, he spent the afternoon running some speciifc testing after booting them and passing the results to jdstrand19:07
loolcking: Hey there and thanks for the power related bugs coming in19:07
rtglool, probably up through making a wi-fi connection, but he's EOD so I'm not positive.19:08
loolcking: albeit the overall state must be sad from your pov  :-)19:08
ckinglool, the ones that should be picked up by QA? ;-)19:08
apwhe booted them and ran twitter and installed hello-world and ran that, to confirm the confinement i believe19:08
loolcking: TBH while fixing power consumption issues is important, we have so many crashers everywhere that we don't have time to look at them19:08
* cking nods, but no Mir test19:08
loolcking: If you can easily boot test with Mir on a recent image, that would be awesome19:09
loolcking: touch /home/phablet/.display-mir + reboot to get Mir19:09
ckinglool, I can do that after I've put my kids to bed19:09
loolcking: you should notice an "almost unperceptible difference in scrolling smoothness"19:09
loolyou can't perceive it, but you should notice19:10
ckingand a perceptible increase in temperature?19:10
loolcking: nighty night19:10
loolcking: an unperceptible warmth19:10
loolj/k19:10
ckingif you have asbestos gloves on19:10
loolit's actually good on mako19:10
apw:)19:10
looljust noticably slower on maguro19:10
loolcking: this can wait til tomorrow BTW19:11
ckingthat's 'cos of a gazillion uevents 19:11
loolpossibly19:11
=== thomi_ is now known as thomi
ckinglool, with Mir enabled on maguro and mako I can't now start the twitter app.19:32
loolcking: that's a known regression which is fixed with latest apparmor-easyprof-ubuntu19:33
jdstrandwell, no-- he is using 1.0.3619:33
loolcking: and should be fixed in #87 I think19:33
ckinglool, i guess you need to double check that with jdstrand as I was testing that today19:34
jdstrandand there are no apparmor denials of significance19:34
jdstrand(just the thumbnailer bug)19:34
loolI took latest image, dist-upgraded, and it starts here19:34
jdstrandcking: curious what ~/.cache/upstart/application.log has to say19:34
ckingapplication-click (ar.com.beuno.hello-world_hello-world_0.9) start/running, process 168219:35
ckingapplication-click (com.ubuntu.developer.webapps.webapp-twitter_webapp-twitter_1.0.3) start/running, process 172519:35
jdstrandthat isn't very illuminating19:35
ckingpositively dark19:36
jdstrandpersonally, I've found that unity sometimes gets in a funk and doesn't launch things. curious if it works after a reboot19:36
jdstrandor rather, display things19:37
jdstrandwell, both actually19:37
* jdstrand is running mir, and it works19:37
* cking reboots and gives it a poke or two19:37
jdstrandcking: another thing to try is to launch the app from a terminal with and without aa-exec-click19:38
jdstrandcking: basically, in a terminal look at the Path in the .desktop file in ~/.local/share/appliations and cd to it, then run the Exec line. can also just run the app with without apparmor by running everything after the '--' in the Exec line19:40
ckingjdstrand, a reboot, and now it works OK19:40
ckingweird19:40
jdstrandheh19:40
jdstrandsee! :)19:40
cking'tis quality19:40
jdstrand'tis a moving target19:40
* cking slips off for the day19:40
jdstrandhopefully once it lands, more people will bang on it and these things will be discovered/fixed19:40
jdstrandcking: thanks again for your help today. have a nice evening :)19:41
ckingmy pleasure19:41
rtgjdstrand, whats the story with Apparmor and the Saucy LTS kernel ? Is it being SRU'd, or is there no impact with Precise user space ?20:23
jdstrandrtg: that is a good question. jjohansen, tyhicks: ^20:27
jjohansenthe userspace policy has to be patched20:28
tyhicksit will likely break userspace20:28
rtgjdstrand, 'cause by about release time we should have that story in place. otherwise bjf will be after blood :)20:28
jjohansennot likely, it will20:28
jdstrandrtg: right, you were correct to bring that up. we will have something for sru20:28
tyhicksdo we have to include the AF_UNIX patch in the Saucy LTS kernel?20:29
rtgjdstrand, looks like apparmor is published, so I'm gonna upload a new kernel20:29
jdstrandtyhicks: can you file a new bug, and add tasks for each package that needs updates?20:29
jdstrandrtg: cool, thanks20:29
rtgtyhicks, I can revert the AF_UNIX patch in the LTS kernel if you think it appropriate20:30
tyhicksjdstrand, jjohansen: I think reverting the patch in the LTS kernel is a good option - what are your thoughts?20:30
rtgprolly I should anyways since folks have been testing saucy LTS on precise already20:30
tyhicksI don't see why we need to have the AF_UNIX patch in precise20:31
rtgI'm good with that20:31
jjohansenagreed, I would revert it there20:31
jdstrandif we do that, I think we need a test case in test-apparmor.py20:32
jdstrandto make sure it is always backed out20:33
tyhicksjdstrand: does test-apparmor.py get run before every LTS kernel release?20:33
jdstrandthe kt runs that as part of their testing, so if test-apaprmr.py is running on precise but has the AF_)UNIX patch applied, it should fail20:33
tyhicksok, good idea20:34
jdstrandyeah, afaik, it is one of a litany of tests they run20:34
jdstrandbjf: that's accurate, correct? ^20:34
jdstranddid we decide how to fix block_supsend?20:35
jdstrandcause that would be a really nice one to fix before the saucy lts kernel hits precise20:35
tyhicksI'm not up on the block_suspend issue - jjohansen? ^20:36
jjohansentyhicks: let me dig out the bug20:37
tyhicksjjohansen: it is probably best to answer jdstrand's question rather than waste time bring me up to speed on it :)20:38
jjohansenerr I though I had. I am for reverting the patch20:39
jdstrandreverting block_suspend too?20:40
jjohansenjdstrand: that is a different issue20:41
jdstrandyes, I thought so :)20:41
jjohansenthat is not apparmor, apparmor just happens to see and mediate it20:42
rtgtyhicks, just to be clear, the AF_UNIX patch is this one ? "apparmor: fix unix domain sockets to be mediated on connection"20:42
jjohansenrtg: yes20:42
rtgjjohansen, ack20:42
jjohansenjdstrand: it would be possible to add a patch to the saucy backport to filter out or map block_suspend to what it was in the precise era20:43
jdstrandI think there are several bugs20:43
jdstrand1199933 is one (also affects raring lts kernel)20:43
jdstrand1205875 is another, but mentions 12.1020:44
jdstrand1228327 is another20:45
jdstrandbut I think 1228327 is a dupe of 119993320:45
* jdstrand marks it as such20:45
jjohansenright so the question is to fix userspace or add a patch to the kernel20:51
jjohansenfixing userspace means updating the parser and the policy20:51
bjfjdstrand, yes we run that20:52
bjfjdstrand, that is also one of the tests we have QA run as part of their testing (SRU and Dev)20:54
jjohansenI don't really care which way we fix it20:55
jdstrandbjf: right, cool. tyhicks, would you mind adding a test to make sure AF_UNIX is backed out when running on precise?20:58
jdstrandjjohansen: let's discuss that after the meeting20:58
tyhicksjdstrand: sure - will do that today20:58
jdstrandtyhicks: thanks20:58
jjohansenjdstrand: sure20:58
* rtg -> EOD21:13
=== _bjf is now known as bjf[alt]

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!