[08:35] <apw>  /b infinity 
[08:35]  * apw yawns
[08:42] <cking> morning apw
[09:49] <xnox> apw: do you know when the next goldfish upload will be made with the compiler switch? does it have to wait on rtg?
[09:51] <apw> xnox, it does not have to wait on rtg no, if you are happy it fixes whatever was broke
[09:51] <apw> xnox, you are likely the only one using it :
[09:51] <apw> :)
[09:52] <xnox> apw: can you please upload it, for me? =)
[09:52] <apw> xnox, will look into it indeed
[09:52] <xnox> apw: thanks a lot!
[10:54] <apw> xnox, can you do a quick test on: http://people.canonical.com/~apw/goldfish-saucy/
[10:54] <apw> and make sure they do what you need, if so i can get it uploaded
[10:55] <xnox> apw: ok, give me a few minutes.
[10:55] <apw> xnox, np
[11:20] <apw> xnox, 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 image
[11:22] <xnox> apw: i have most up-todate userspace (saucy rootfs tarball as running on ubuntu touch / all other ports)
[11:22] <xnox> apw: and it's our initramfs, booting ubuntu direct.
[11:23] <xnox> apw: everything looks good =)
[11:24] <xnox> apw: note that I only tried armhf, no support for i386 yet.
[11:24] <apw> xnox, ok fine
[13:09]  * henrix -> lunch
[13:47] <apw> rtg, yo, i was just about to upload the goldfish kernel to fix this compiler issue, any objections
[13:47] <apw> rtg, alfo fyi, the touch kernels are all sitting in the ckt ppa ready for publishing
[13:47] <rtg> apw, rock and roll assuming xnox still likes it.
[13:47] <apw> xnox, is very happy
[13:47] <xnox> =)
[13:47] <rtg> cool
[14:31] <apw> rtg, ok linux-goldfish is also in ckt as it also ought to wait on the userspace changes to preceed it
[14:32] <apw> rtg, we should also decide if we are going to upload the tip of master-next in step, which i have not yet done
[14:32] <rtg> apw, right. in fact I was just reading that bug report from jdstrand
[14:32] <apw> its alll a bit of a nightmare getting thigs in order
[14:33] <rtg> apw, hopefully userspace will all be sorted by tomorrow ?
[14:41] <apw> rtg, i am hoping today your time as it were
[14:41] <apw> as the kernels are already built generally that will speed up our bit
[14:41] <rtg> apw, well, looking at the last comment it appears that jdstrand switched it back to 'in-progress'
[14:42] <apw> there is an issue remaining which is kernel related ultimatly that jjohansen does not intend to fix but to work around in userspace
[14:42] <apw> but i will double check
[15:02] <jsalisbury> **
[15:02] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:02] <jsalisbury> **
[15:22] <xnox> apw: rtg: what's the bug number / reference for these upload?
[15:22] <xnox> *uploads
[15:24] <apw> xnox, for the aa3 uploads ?
[15:24] <xnox> apw: 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/1208988
[15:25] <apw> xnox, yes that is the umbrella
[15:33] <xnox> apw: rtg: can you like just shove the linux-goldfish through, since it really can't regress since emulator is still not working =)
[15:34] <xnox> apw: rtg: it's unseeded so it will even get an auto-accept through the unapproved.
[15:34] <rtg> xnox, its ready to be pocket copied. are you sure the apparmor mess won't nail you ?
[15:34] <xnox> rtg: nope, i have apparmor disabled tbh at the moment.
[15:34] <rtg> apw ^^
[15:35] <xnox> apw: rtg: i'm nowhere near to care about apparmor yet, I'm yet to see a display output from the emulator
[15:52] <xnox> rtg: apw: thanks a lot.
[15:52] <rtg> xnox, apw did all the heavy lifting
[15:53] <apw> xnox, just got accepted, should be in the archive in about 10m
[16:02] <slangasek> \o/
[16:16] <ricotz> rtg, hi :), is it known that the arch-all header packages of the recent mainline kernel builds are missing?
[16:16] <rtg> ricotz, it is known
[16:16] <ricotz> rtg, ok, thanks
[16:17] <rtg> ricotz, a fix has been applied, builds are in progress. so says apw.
[16:17] <ricotz> great! :)
[16:18] <apw> indeed, the ones i know of with missing headers are re-queued
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:56] <jsalisbury> ##
[18:27] <rtg> arges, so whats the story on this readline patch ? are you getting any upstream traction ?
[18:28] <arges> rtg: no i haven't done anything upstream, mostly just testing on my end
[18:29] <rtg> arges, were you thinking that we might carry it forever ?
[18:30] <arges> rtg: 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 him
[18:31] <rtg> arges, are you referring to https://lkml.org/lkml/2013/9/11/825 ?
[18:31] <arges> He'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 well
[18:31] <arges> Yes
[18:33] <arges> rtg: 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 patch
[18:33] <rtg> ok, seems like there has been reasonable testing with saucy.
[18:33] <rtg> arges, unless this patch is the root of many suspend/resume issues :)
[18:34] <arges> I 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't
[18:34] <arges> rtg: which bugs? I'd be happy to test with and without this patch.
[18:34] <rtg> arges, with the patch I presume
[18:34] <arges> rtg: yup
[18:34] <rtg> arges, just kidding about the s/r issue.
[18:34] <arges> oh ok : ) had me worried...
[18:35] <rtg> arges, most of them have s/r problems even on mainline
[18:35] <rtg> if not, jsalisbury would be all over me
[18:40] <rtg> jdstrand, does apparmor-easyprof-ubuntu (1.0.36) satisfy userspace requirements for the set of kernel patches from jjohansen ?
[18:40] <jdstrand> rtg: no. need apparmor userspace
[18:40] <jdstrand> rtg: that is ready and being discussed in #ubuntu-ci-eng
[18:40] <rtg> jdstrand, ok, lemme know when all is ready.
[18:40] <rtg> we've got the kernels staged in a PPA
[18:59] <jdstrand> rtg (and apw): fyi, apparmor was accepted and making its way to proposed. note, lool mentioned something about waiting on the kernel. please coordinate with him
[19:00] <rtg> jdstrand, ack
[19:00] <lool> rtg: hey
[19:00] <lool> rtg: trying to land mir tonight, switching kernels at the same time is a bit much, so I was thinking tomorrow would be a better time
[19:00] <rtg> lool, they are all ready staged in the kernel ckt PPA, so you can get an AA to copy them at your leisure
[19:00] <lool> rtg: it's a two steps thing IIUC: kernels are uploaded and built, then we rebuild "android" package that generates all the boot images from them
[19:01] <jdstrand> lool: I would think the non-touch kernels could go now though
[19:01] <lool> rtg: ok; didn't know the kernels were ppa-copied into the archive too  :-)
[19:01] <lool> jdstrand: oh yes
[19:01] <lool> rtg: I dont want to block anything non-touch though
[19:01] <jdstrand> but I am not pushing for that. whatever is easier for people
[19:01] <lool> rtg: jdstrand has uploaded all apparmor bits now (in -proposed)
[19:02] <rtg> lool, no problem. I'm about to fire up the distro kernel as soon as I see apparmor roll into release
[19:03] <lool> rtg: outside of apparmor AF_UNIX, is anything else staged in the touch kernels?
[19:03] <rtg> lool, nope, apw and I kept changes to a minimum.
[19:04] <lool> rtg: Ok; thanks
[19:04] <lool> rtg: added to landing plan
[19:04] <apw> lool, rtg actually there is also ogras ureadahead patch in there in two of them
[19:05] <rtg> ah, forgot about the trace patch
[19:06] <lool> apw: ah right, he mentioned that
[19:06] <lool> that's ok; noted down though
[19:06] <rtg> lool, cking has tested all touch kernel variants (I think)
[19:07] <lool> rtg: oh wow, cool
[19:07] <lool> rtg: boot tested?
[19:07] <lool> might be worth testing with Mir on mako + maguro
[19:07] <lool> cking: ^
[19:07] <apw> lool, confirmed, he spent the afternoon running some speciifc testing after booting them and passing the results to jdstrand
[19:07] <lool> cking: Hey there and thanks for the power related bugs coming in
[19:08] <rtg> lool, probably up through making a wi-fi connection, but he's EOD so I'm not positive.
[19:08] <lool> cking: albeit the overall state must be sad from your pov  :-)
[19:08] <cking> lool, the ones that should be picked up by QA? ;-)
[19:08] <apw> he booted them and ran twitter and installed hello-world and ran that, to confirm the confinement i believe
[19:08] <lool> cking: TBH while fixing power consumption issues is important, we have so many crashers everywhere that we don't have time to look at them
[19:08]  * cking nods, but no Mir test
[19:09] <lool> cking: If you can easily boot test with Mir on a recent image, that would be awesome
[19:09] <lool> cking: touch /home/phablet/.display-mir + reboot to get Mir
[19:09] <cking> lool, I can do that after I've put my kids to bed
[19:09] <lool> cking: you should notice an "almost unperceptible difference in scrolling smoothness"
[19:10] <lool> you can't perceive it, but you should notice
[19:10] <cking> and a perceptible increase in temperature?
[19:10] <lool> cking: nighty night
[19:10] <lool> cking: an unperceptible warmth
[19:10] <lool> j/k
[19:10] <cking> if you have asbestos gloves on
[19:10] <lool> it's actually good on mako
[19:10] <apw> :)
[19:10] <lool> just noticably slower on maguro
[19:11] <lool> cking: this can wait til tomorrow BTW
[19:11] <cking> that's 'cos of a gazillion uevents 
[19:11] <lool> possibly
[19:32] <cking> lool, with Mir enabled on maguro and mako I can't now start the twitter app.
[19:33] <lool> cking: that's a known regression which is fixed with latest apparmor-easyprof-ubuntu
[19:33] <jdstrand> well, no-- he is using 1.0.36
[19:33] <lool> cking: and should be fixed in #87 I think
[19:34] <cking> lool, i guess you need to double check that with jdstrand as I was testing that today
[19:34] <jdstrand> and there are no apparmor denials of significance
[19:34] <jdstrand> (just the thumbnailer bug)
[19:34] <lool> I took latest image, dist-upgraded, and it starts here
[19:34] <jdstrand> cking: curious what ~/.cache/upstart/application.log has to say
[19:35] <cking> application-click (ar.com.beuno.hello-world_hello-world_0.9) start/running, process 1682
[19:35] <cking> application-click (com.ubuntu.developer.webapps.webapp-twitter_webapp-twitter_1.0.3) start/running, process 1725
[19:35] <jdstrand> that isn't very illuminating
[19:36] <cking> positively dark
[19:36] <jdstrand> personally, I've found that unity sometimes gets in a funk and doesn't launch things. curious if it works after a reboot
[19:37] <jdstrand> or rather, display things
[19:37] <jdstrand> well, both actually
[19:37]  * jdstrand is running mir, and it works
[19:37]  * cking reboots and gives it a poke or two
[19:38] <jdstrand> cking: another thing to try is to launch the app from a terminal with and without aa-exec-click
[19:40] <jdstrand> cking: 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 line
[19:40] <cking> jdstrand, a reboot, and now it works OK
[19:40] <cking> weird
[19:40] <jdstrand> heh
[19:40] <jdstrand> see! :)
[19:40] <cking> 'tis quality
[19:40] <jdstrand> 'tis a moving target
[19:40]  * cking slips off for the day
[19:40] <jdstrand> hopefully once it lands, more people will bang on it and these things will be discovered/fixed
[19:41] <jdstrand> cking: thanks again for your help today. have a nice evening :)
[19:41] <cking> my pleasure
[20:23] <rtg> jdstrand, 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:27] <jdstrand> rtg: that is a good question. jjohansen, tyhicks: ^
[20:28] <jjohansen> the userspace policy has to be patched
[20:28] <tyhicks> it will likely break userspace
[20:28] <rtg> jdstrand, 'cause by about release time we should have that story in place. otherwise bjf will be after blood :)
[20:28] <jjohansen> not likely, it will
[20:28] <jdstrand> rtg: right, you were correct to bring that up. we will have something for sru
[20:29] <tyhicks> do we have to include the AF_UNIX patch in the Saucy LTS kernel?
[20:29] <rtg> jdstrand, looks like apparmor is published, so I'm gonna upload a new kernel
[20:29] <jdstrand> tyhicks: can you file a new bug, and add tasks for each package that needs updates?
[20:29] <jdstrand> rtg: cool, thanks
[20:30] <rtg> tyhicks, I can revert the AF_UNIX patch in the LTS kernel if you think it appropriate
[20:30] <tyhicks> jdstrand, jjohansen: I think reverting the patch in the LTS kernel is a good option - what are your thoughts?
[20:30] <rtg> prolly I should anyways since folks have been testing saucy LTS on precise already
[20:31] <tyhicks> I don't see why we need to have the AF_UNIX patch in precise
[20:31] <rtg> I'm good with that
[20:31] <jjohansen> agreed, I would revert it there
[20:32] <jdstrand> if we do that, I think we need a test case in test-apparmor.py
[20:33] <jdstrand> to make sure it is always backed out
[20:33] <tyhicks> jdstrand: does test-apparmor.py get run before every LTS kernel release?
[20:33] <jdstrand> the 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 fail
[20:34] <tyhicks> ok, good idea
[20:34] <jdstrand> yeah, afaik, it is one of a litany of tests they run
[20:34] <jdstrand> bjf: that's accurate, correct? ^
[20:35] <jdstrand> did we decide how to fix block_supsend?
[20:35] <jdstrand> cause that would be a really nice one to fix before the saucy lts kernel hits precise
[20:36] <tyhicks> I'm not up on the block_suspend issue - jjohansen? ^
[20:37] <jjohansen> tyhicks: let me dig out the bug
[20:38] <tyhicks> jjohansen: it is probably best to answer jdstrand's question rather than waste time bring me up to speed on it :)
[20:39] <jjohansen> err I though I had. I am for reverting the patch
[20:40] <jdstrand> reverting block_suspend too?
[20:41] <jjohansen> jdstrand: that is a different issue
[20:41] <jdstrand> yes, I thought so :)
[20:42] <jjohansen> that is not apparmor, apparmor just happens to see and mediate it
[20:42] <rtg> tyhicks, just to be clear, the AF_UNIX patch is this one ? "apparmor: fix unix domain sockets to be mediated on connection"
[20:42] <jjohansen> rtg: yes
[20:42] <rtg> jjohansen, ack
[20:43] <jjohansen> jdstrand: 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 era
[20:43] <jdstrand> I think there are several bugs
[20:43] <jdstrand> 1199933 is one (also affects raring lts kernel)
[20:44] <jdstrand> 1205875 is another, but mentions 12.10
[20:45] <jdstrand> 1228327 is another
[20:45] <jdstrand> but I think 1228327 is a dupe of 1199933
[20:45]  * jdstrand marks it as such
[20:51] <jjohansen> right so the question is to fix userspace or add a patch to the kernel
[20:51] <jjohansen> fixing userspace means updating the parser and the policy
[20:52] <bjf> jdstrand, yes we run that
[20:54] <bjf> jdstrand, that is also one of the tests we have QA run as part of their testing (SRU and Dev)
[20:55] <jjohansen> I don't really care which way we fix it
[20:58] <jdstrand> bjf: right, cool. tyhicks, would you mind adding a test to make sure AF_UNIX is backed out when running on precise?
[20:58] <jdstrand> jjohansen: let's discuss that after the meeting
[20:58] <tyhicks> jdstrand: sure - will do that today
[20:58] <jdstrand> tyhicks: thanks
[20:58] <jjohansen> jdstrand: sure
[21:13]  * rtg -> EOD