=== chihchun_afk is now known as chihchun
[06:43] <zbenjamin> Mirv:   crap, failed
[07:00] <Mirv> zbenjamin: now looking good!
[07:00] <zbenjamin> Mirv: yay!
[07:16] <mardy> trainguards: just to confirm, is there something I should do on silo 31 (whose status is "is in the Proposed pocket") to get it landed?
[07:18] <Mirv> mardy: no, the gcc5 folks are on it. but if you need trunks updated, we can do that for you.
[07:18] <robru> mardy: if you click on the status there it'll open the migration page and you can see what is holding it back
[08:23] <tsdgeos> trainguards: how do i abandon a change if abandon doesn't really abandon it?
[08:24] <sil2100> tsdgeos: it doesn't?
[08:24] <robru> tsdgeos: click "clean" on the dashboard and check ONLY_FREE_SILO to free the silo
[08:24] <tsdgeos> sil2100: the popup tells me
[08:24] <sil2100> tsdgeos: ah
[08:24] <sil2100> tsdgeos: first you need to clean the silo
[08:25] <sil2100> As robru says ^
[08:25] <tsdgeos> ok
[08:26] <tsdgeos> i think it worked?
[08:26] <robru> Oh god why am i still up
[08:26] <tsdgeos> not sure to be honest
[08:26] <tsdgeos> https://requests.ci-train.ubuntu.com/#/?show=aacid doesn't show anything anymore
[08:26] <tsdgeos> but https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-016 still does
[08:26] <robru> tsdgeos: paste the link to the clean job you ran
[08:26] <tsdgeos> oh not anymore
[08:26] <tsdgeos> ok
[08:26] <robru> There it goes
[08:27] <tsdgeos> would be nice if the warning in "Abandon" did tell you what to do
[08:27] <tsdgeos> or even did it :D
[08:27] <robru> tsdgeos: yeah bileto is not able to trigger Jenkins jobs
[08:28] <robru> That would be a huge undertaking to implement
[08:31] <Mirv> it's pretty weird seeing robru up at this hour, even knowing his late nights
[08:31] <Mirv> it's like noon here :)
[08:31] <robru> 1:30 here
[08:31] <robru> AM
[08:32] <robru> I'm not even really working, just watching tv... IRC on my phone.
[08:34] <robru> tsdgeos: please file a bug against lp:bileto, i can expand that message with the instructions tomorrow.
[08:35] <tsdgeos> robru: awesome, i will
[08:52] <sil2100> Ouch
[09:21] <sil2100> Damn, looks like people actually read my e-mails now, need to start thinking about what I write there!
[09:21] <sil2100> ;p
[09:26] <sil2100> Seriously though, ygh, I'll have to straighten some things up
[09:27] <sil2100> ogra_: hey! I saw those logs with the debugging info - looks like the dates were correct for profiles but messed up in the cache
[09:27] <sil2100> ogra_: did jdstrand figure out where those get corrupted?
[09:27] <ogra_> sil2100, yes, tyhicks figured it out
[09:28] <sil2100> Issue in apparmor in the end?
[09:28] <ogra_> apparmor rewrites the file stamps at the end and there was a bu in that code
[09:28] <ogra_> *bug
[09:28] <sil2100> Ok, good to know :)
[09:28] <ogra_> sil2100, http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/view/head:/parser/policy_cache.c#L169
[09:29] <ogra_> utimes gets handed over the whole array (t), not just the relevant part
[09:30] <sil2100> hah, good one
[09:31] <sil2100> ogra_: thanks for helping debugging that - did you revert the debugging changes already?
[09:31] <ogra_> sil2100, i didnt plan to revert them at all ;)
[09:32]  * ogra_ recently made it a habit to just keep such stuff around so we dont need to enable it next time we need to resaers something at the same place
[09:32] <sil2100> uh oh! Well, I think jdstrand asked for some 'touch /some_file_here' ones too, not sure if we want to have new files in our filesystem
[09:32] <ogra_> *research
[09:32] <sil2100> Would like at least those removed
[09:32] <ogra_> oh, right, yeah, these two lines need to go
[09:32] <ogra_> good catch ;)
[09:33] <ogra_> also, should we touch the cache files to get usable images again and to give the guys more time to fix it ?
[09:44] <sil2100> Ah, so there's no fix for that yet?
[09:45] <sil2100> In that case I suppose we could do a workaround like that, I suppose it shouldn't have any serious implications
[09:45] <ogra_> ok, will include that when i remove the two files
[09:46] <sil2100> I wonder if we could make this touch workaround only for wily images for now
[09:46] <sil2100> Actually, nevermind that
[10:05] <greyback> trainguards: could someone please delete the wily packages from silo10 please - I reconfigured it from dual to vivid-only, so the wily package still hanging around
[10:05] <sil2100> greyback: on it!
[10:05] <greyback> cheers
[10:06] <sil2100> greyback: done
[10:06] <greyback> sil2100: thank you
[10:09] <ogra_> sil2100, hmm, i only just looked at the log, i guess i'll revert one version to the simple ls -l
[10:09] <sil2100> Yeah, there was a LOT of ls'es in the last builds
[10:09] <sil2100> Sounds ok to me
[10:10] <ogra_> yup, i didnt expect it to double the size of the log :)
[10:41]  * Mirv hugs pete-woods for being such an excellent bug fixer/triager!
[10:42] <pete-woods> Mirv: :D
[11:02] <greyback> dch: fatal error at line 1141: New version specified (0.4.5+15.04.20150812-0ubuntu1) is less than the current version number (0.4.5+15.10.20150804.1-0ubuntu1)!
[11:03] <greyback> but but, 0.4.5+15.04.20150812-0ubuntu1 > 0.4.5+15.10.20150804.1-0ubuntu1
[11:04] <Laney> false
[11:04] <Laney> 15.04 -> 15.10
[11:05] <greyback> ah, dammit
[11:05] <greyback> Laney: thanks, now I know what's wrong
[11:07] <Laney> np!
[11:44] <ogra_> sil2100, i kicked an image, seems livecd-rootfs is there)
=== _salem is now known as salem_
[11:58] <sil2100> ogra_: thanks!
[11:58] <ogra_> sil2100, bah, armhf fails now too with dependency errors
[11:58] <ogra_> The following packages have unmet dependencies:
[11:58] <ogra_>  ubuntu-touch : Depends: libzen0 but it is not going to be installed
[11:58] <ogra_> E: Unable to correct problems, you have held broken packages.
[11:59] <ogra_> bitten by gcc5 too now
[11:59] <ogra_> (i guess)
[12:07] <sil2100> I'll look into that with the others
[12:07]  * sil2100 off to prepare lunch
[12:09] <kgunn> trainguards so it seems unity-api for wily finally got released (and out of proposed pocket)
[12:10] <kgunn> but the mp's didn't merge, and dashboard saying it's still there ?
[12:10] <kgunn> https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-035
[12:10] <kgunn> at least, when i look at excuses, unity-api no longer there
[12:10] <seb128> ogra_, pitti was mentioning it earlier on #ubuntu-devel
[12:11] <kgunn> yep...lp proj page showing released... https://launchpad.net/ubuntu/+source/unity-api
[12:12] <kgunn> should i manual merge those mp's or just wait ... ?
[12:14] <Mirv> kgunn: it seems 035 has a different version 7.98+15.10.20150803-0ubuntu1 while archives have https://launchpad.net/ubuntu/+source/unity-api/7.99+15.10.20150804-0ubuntu1
[12:14] <Mirv> kgunn: I don't see the "added alerting/setAlerting API to LauncherModel and LauncherItem interfaces" in https://launchpad.net/ubuntu/+source/unity-api/+changelog
[12:15] <Mirv> kgunn: so it'd seem to me like conflicting landings
=== alan_g is now known as alan_g|lunch
[12:20] <kenvandine> jgdx, ^^ when i tried to publish
[12:20] <kenvandine> the only unbuilt revision was the translator comments
[12:20] <kenvandine> i kicked a rebuild
[12:28] <jgdx> kenvandine, :s bitten by a specific build once again
[12:28] <jgdx> thanks
[12:31] <kenvandine> jgdx, np
[12:31] <kenvandine> jgdx, thankfully it's a trivial commit :)
[12:41] <tsdgeos> sil2100: so after i've set https://requests.ci-train.ubuntu.com/#/?req=147 to "Ready for QA" i just wait, right?
[12:45] <jibel> tsdgeos, when you set it to ready for QA, it creates a card on the QA board, in this case https://trello.com/c/wgbU6IWH/2161-147-ubuntu-landing-016-unity8-tsdgeos-mzanetti I suppose, then a tester will pick it up for verification, and will mark the request granted or failed.
[12:46] <jibel> so yeah, just wait
[12:46] <tsdgeos> jibel: awesomeness
[12:56] <jhodapp> davmor2, silo 48 is ready to test
[12:56] <jhodapp> davmor2, there's one bug with it that I'm fixing with ringtone
[12:59] <jibel> jhodapp, do you mean you'll update 48 with the fix or do a separate landing after 48?
[13:00] <jhodapp> jibel, I'll update 48
=== alan_g|lunch is now known as alan_g
[13:01] <jhodapp> jibel, ringtone isn't working on incoming call, so it's a critical one to fix
[13:06] <jibel> jhodapp, okay, I'll block the silo until the fix is in.
[13:07] <jhodapp> jibel, is that a general policy not to test until then? every other part of the test plan can be gone over and there's a lot to test
[13:08] <jibel> jhodapp, we start testing when it's ready. If there is a known issue that will be fixed, then it is not ready. And there are other silos ready in the queue
[13:09] <jhodapp> jibel, alright
[13:14] <pete-woods> kenvandine: silo 46 built ^
[13:15] <kenvandine> pete-woods, thx
[13:15] <kenvandine> pete-woods, publishing
[13:15] <pete-woods> :D
[13:21] <kgunn> Mirv: thanks (didn't see your ping til now), so that is strange, i guess this was sort of a race to a rebuild
[13:21] <kgunn> so what should we do ?
[13:24] <kgunn> from the looks of it, should i just abandon that silo ?
[13:25] <kgunn> seems unity8 which is not showing proposed, also has a package more recent in archive than in the silo 35 ppa
[13:33] <Mirv> kgunn: or rebuild and republish?
[13:34] <kgunn> Mirv: ...actually, the changelog for unity8 is inclusive of this silo
[13:35] <Mirv> kgunn: ok. I was only worried about not seeing the 035's macslow's commit in any of the published changelogs.
[13:35] <kgunn> Mirv: it's like unity8 was all correct and succeeded, unity8 MP hasn't merged...b/c unity-api had this weird race
[13:35] <alan_g> cihelp It looks like we're now building with g++5 with g++4 packages installed (which doesn't work: http://paste.ubuntu.com/12061672/); full log: https://jenkins.qa.ubuntu.com/job/mir-wily-amd64-ci/692/console
[13:36] <kgunn> Mirv: also, silo 35 was strictly a no change rebuild to help get over the gcc5 hump, so if the packages are getting through...i don't think we need this silo at all...
[13:36] <kgunn> so can i just abandon it?
[13:36] <kgunn> hmmm unity8 technically should have that mp merged tho...
[13:39] <Mirv> kgunn: yeah, I think you should abandon it but just find out where the Launchpad got that macslow's commit message from (even though MP:s were no-ops)
[13:42] <fginther> alan_g, hi, I'll take a look. If this is just a matter of removing g++4 from the chroots, that should be something we can fix within an hour or two
[13:44] <kenvandine> pete-woods, your silo 53 needs a rebuild now
[13:44] <pete-woods> kenvandine: cool, just sorting that now :)
[13:44] <kenvandine> pete-woods, i merged 46, so it's good to rebuild
[13:44] <pete-woods> :)
[13:44] <alan_g> fginther: removing g++4 wouldn't help. It looks like g++ has suddenly changed from g++4 to g++5 (but all the system packages are still g++4 builds)
[13:45] <kenvandine> pete-woods, since we have stuff held in -proposed for the gcc5 transition, i force merged the silo so we can move on
[13:45] <alan_g> So I'd rather remove g++5
[13:45] <pete-woods> kenvandine: thanks. I thought something magic like that would have to happen
[13:45] <pete-woods> I thought there were no problems with the g++5 landing? *ducks*
[13:46] <kgunn> Mirv: sorry to continue to pester, which macslow commit are you talking about ?
=== marcusto_ is now known as marcustomlinson
[13:47] <Mirv> kgunn: this one mentioned in the no-change rebuild's changelog: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-035/+sourcepub/5274714/+listing-archive-extra
[13:47] <Mirv> kgunn: so just wondering which MP it is and can it be double checked it's actually in. no idea where LP picked the idea of it from.
[13:47] <fginther> alan_g, hmm. I'll have to look a little closer then as I'm not sure g++5 just won't get added again on the next update. I'll keep you updated
[13:48] <kgunn> woa...ok
[13:48] <alan_g> fginther: I don't mind it being there, just don't make it the default without providing the rebuilt packages from proposed
[13:49] <kgunn> Mirv: weird, yeah...but that commit is on trunk from some time back, wonder if this was from dual landing shake out
[13:50] <Mirv> kgunn: ok, then the silo good to free up
[13:50] <Mirv> kgunn: maybe so
[13:50] <jdstrand> sil2100, ogra_: fyi, we have a patch for the timestamp issue. it is wily-specific and we will likely be able to upload later today, tomorrow at the latest. it sounds like wily images are broken for other reasons so not sure you need to do a workaround at this point. obviously that is up to you
[13:50] <fginther> alan_g, Ack, a completely new chroot from scratch should solve this (I think)... Will have to see.
[13:51] <ogra_> jdstrand, well, i think it cant do harm and will shield us the next time from image failures
[13:56] <jdstrand> well, I leave that up to you. the patchset for the fix includes new tests to make sure this can't happen again too
=== salem_ is now known as _salem
=== _salem is now known as salem_
[14:25] <sil2100> Mirv: I uploaded a version-sync of qtdeclarative-opensource-src-gles to have the exact same version of it as the non-gles one, since for unknown to me reasons through the recent thumbnailer upload shlibs set the dep to the exact 5.4.1-1ubuntu8 version
[14:25] <sil2100> Mirv: almost as if this version added some symbol the thumbnailer was using
[14:26] <sil2100> Well, anyway, this should push the i386 vivid builds further
[14:26]  * sil2100 will check once it builds
[14:29] <dobey> trainguards: can i guet someone to click "try again" for https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021/+build/7790724 ?
[14:29] <sil2100> dobey: sure
[14:30] <dobey> thanks
[14:30] <sil2100> dobey: retried
[14:30] <dobey> thanks
[14:30] <sil2100> np :)
[14:44] <awe_> sil2100, question for you about bileto.  What's the equivalent of the old spreadsheet "Tested" column in bileto?  Are test results just now added as general comments?
[14:44] <sil2100> awe_: hey!
[14:45] <sil2100> awe_: so, if you want to mark a silo as tested you need to edit the landing in bileto and change the QA Signoff Status field accordingly: https://wiki.ubuntu.com/citrain/LandingProcess#qastatus <- some explaination here
[14:46] <sil2100> Any additional information about what and where you tested can be added as comments
[14:46] <awe_> got it
[14:47] <awe_> hmmm, so we went from required the tester, img #, and device to be recorded ( which frankly was missing channel to be fully qualified ) to voluntary recording of this info?
[14:47] <awe_> what's the lp project so I can suggest an enhancement?
[14:48] <cyphermox> ^ please don't ack, there will be another revision on top
[14:48] <sil2100> Yeah, we already have a bug suggesting some improvements to it, but you can fill in another one with proposing the detailed entries
[14:48] <cyphermox> sil2100:
[14:48] <sil2100> awe_: https://bugs.launchpad.net/bileto
[14:48] <awe_> thanks sil2100
[14:48] <sil2100> awe_: https://bugs.launchpad.net/bileto/+bug/1483635 <- I filled in this a few days ago
[14:49] <ubot5> Ubuntu bug 1483635 in Bileto "Setting silo status is confusing for people" [Wishlist,New]
[14:49] <sil2100> You can +1 it if you think that's also a problem
[14:49] <awe_> sil2100, ok, I'll take a look and comment there if appropriate
[14:49] <sil2100> Thanks o/
[14:51] <sil2100> Oh, the qtdeclarative no-change rebuild just failed
[14:55] <dobey> hmm
[14:56] <dobey> since gcc5 made it to release now, are devel-proposed images going to start building consistently again?
[15:21] <sil2100> dobey: well... not entirely, not yet at least - but soon, yes :)
[15:21] <sil2100> We're waiting for an apparmor fix to get released
[15:22] <sil2100> Interesting, a retry helped, strange
=== chihchun is now known as chihchun_afk
[16:06] <sil2100> ogra_, jibel: kicking a new vivid image
[16:06] <sil2100> Need to test some recent i386 build fixes
[16:06] <ogra_> sure sure :)
[16:09] <sil2100> I wasn't able to test everything as I had some strange things happening in my chroot
[16:13] <Mirv> sil2100: thanks. that version indeed added a backported feature from Qt 5.6 exactly for thumbnailer's use.
[16:14] <sil2100> Mirv: ok :) it's built now in the overlay PPA, the i386 builds still fail but for other reasons
[16:14] <slangasek> sil2100, jibel, davmor2: hi, so since packages are starting to make their way into wily now for gcc-5, I think it's time to restart the image builds against wily without -proposed; do you agree?
[16:15] <sil2100> slangasek: makes sense, +1 on that
[16:16] <sil2100> slangasek: ogra_ pushed a temporary workaround for the custom tarball timestamp corruption, but the apparmor guys already have a fix ready for release as well
[16:16] <sil2100> So at least the importer shouldn't die with the next image
[16:17] <tyhicks> the apparmor fix and the corresponding new tests are undergoing review
[16:17] <tyhicks> we hope to have an apparmor upload ready today
[16:20] <davmor2> slangasek: I care not either way I think you, sil2100 and jibel are all in better positions to decide this than I.  I would however like to grab the first cdimage with gcc5 on and test that it at least installed and ran, but other than that I care not :)
[16:20] <slangasek> davmor2: well, that already exists
[16:20] <slangasek> (or should; let me just double-check)
[16:21] <jibel> slangasek, agreed
[16:21] <slangasek> davmor2: yes, 20150812 is gcc-5.  Not all the packages have transitioned with it yet however, so it's not the same thing as a full dist-upgrade to wily-proposed
[16:24] <slangasek> jibel, sil2100: ok I've adjusted the crontab for the wily touch images to build without -proposed again, and kicked off a run; once that's done the importer can be adjusted to pull them into devel-proposed again instead of devel-proposed-g++5
[16:24] <slangasek> (assuming the importer is working at that point)
[16:24] <sil2100> slangasek: ok, I'm testing the importer to import the latest wily-proposed build
[16:24] <sil2100> To see if ogra_'s workaround worked
[16:26] <ogra_> there was no image with my fix yet ... meta was broken
[16:26] <sil2100> Ouch
[16:26] <sil2100> Ok
[16:27] <sil2100> Right, forgot about that
[16:27] <ogra_> (i told you above when you told me pitti had said it would be)
[16:27]  * sil2100 has bad short term memory it seems
[16:27] <ogra_> overheating brain i guess :)
[16:28] <sil2100> It's so hot here that I would suppose that's actually possible
[16:29] <ogra_> yeah, here too
[16:34] <jhodapp> sil2100, I'm not a debian package expert nor PPA...any ideas why the new packages in silo 48 aren't selected for upgrading on vivid when using that PPA?
[16:35] <jhodapp> sil2100, seems like all of those package version numbers are greater than what's in vivid+overlay, so why wouldn't they be selected for upgrading?
[16:36] <sil2100> jhodapp: hm, everything looks good
[16:37] <jhodapp> sil2100, I have always seen this with the vivid overlay and landing PPAs
[16:37] <sil2100> jhodapp: how do you perform the upgrades?
[16:37] <sil2100> Ah, probably pin priority
[16:37] <jhodapp> sil2100, I've tried both citrain and add-apt-repository
[16:37] <sil2100> jhodapp: when adding the PPA, did you adjust the pin priority?
[16:37] <jhodapp> nope, don't know anything about that
[16:38] <sil2100> jhodapp: https://wiki.ubuntu.com/LandingTeam/SiloTestingGuidelines#Install_silos_with_overlay_PPA_enabled :)
[16:39] <jhodapp> interesting, alright thanks
[16:42] <jhodapp> sil2100, a higher pin priority number means a higher priority for considering package versions?
[16:43] <sil2100> Yeah, the PPAs with higher priorities are checked first for packages, even if they have lower versions
[16:46] <sil2100> slangasek, ogra_: so, the last wily build anyway succeeded in importing, even though the timestamps are clearly wrong - but by accident they seem to be good enough for tarfile to not die (as the year is this time 1954)
[16:46] <oSoMoN> jibel, FYI, we have a fix ready for the issue you found yesterday while testing the "find in page" functionality, it will go in the next landing
=== alan_g is now known as alan_g|EOD
[17:20] <bzoltan_> sil2100:  do you know why the silo11 is marked as dirty?
[17:22] <sil2100> bzoltan_: looks like some UITK landing finally migrated from -proposed and got merged into trunk
[17:22] <sil2100> ubuntu-ui-toolkit 1.3.1584+15.10.20150730-0ubuntu1 <- this version for wily finally migrated yesterday
[17:22] <bzoltan_> sil2100:  wow :) That is good news indeed .. So I assume I want to sync the landing branch with the trunk and push a new build
[17:23] <sil2100> bzoltan_: yeah, sorry you have to rebuild though ;p
[17:23] <dobey> https://jenkins.qa.ubuntu.com/job/wily-boottest-unity-scope-click/lastBuild/console
[17:23] <dobey> hrmm :(
[17:24] <bzoltan_> sil2100:  It is not a problem.. the silo17 has anyway a fix what unblocks the UITK landing... without that silo17 I cannot test the UITK silo
[17:24] <ogra_> sil2100, well, i see that my code actually changed the timestamps
[17:25] <ogra_> sil2100, http://paste.ubuntu.com/12063458/
[17:25] <ogra_> from 1987 to today :)
[17:26] <ogra_> so the workaround works around :)
[17:27] <sil2100> Yay ;)
[17:28] <sil2100> Let's do bets on what date it would set it to tomorrow!
[17:28] <ogra_> and i see your x86 build succeeded too
[17:28] <ogra_> what was it ?
[17:28] <ogra_> haha, i bet on 1973
[17:29] <ogra_> jdstrand, hold back that apparmor fix, we have a thing going on
[17:29] <ogra_> :)
[17:29] <jdstrand> ogra_: ack
[17:40] <dobey> how can i know why exactly some boottest is failing?
[17:41] <dobey> and whom do i bug to retry failed ones?
[17:41] <dobey> trainguards: ^^
[17:49] <robru> dobey: you need to bug cihelp about that
[17:49] <robru> dobey: and the excuses page should link through to the jenkins job, which you can check console output to see the failure
[17:49] <dobey> robru: unfortunately the console output is pretty vague
[17:49] <dobey> https://jenkins.qa.ubuntu.com/job/wily-boottest-unity-scope-click/lastBuild/console
[17:50] <robru> dobey: looks pretty clear to me, the  device failed to provision. so you need cihelp to investigate it. as far as I understand they just retry and 99% of the time it works.
[17:51] <dobey> cihelp ^^ can you retry the boottest please then?
[17:52] <fginther> dobey, I've restarted it
[17:52] <dobey> ok, thanks fginther
[17:53] <fginther> dobey, will keep an eye on it to make sure it finishes ok
[18:22] <dobey> fginther: oh, i guess it's failing now because there's no wily devel-proposed image with the gcc5 stuff, and ubuntu-touch-meta requires it now?
=== jhodapp is now known as jhodapp|gym
[18:26] <fginther> dobey, hmm. Well, it looks like there is a problem installing what was the latest image, which is causing problems for unity-scope-click. Not sure yet on ubuntu-touch-meta
[18:27] <dobey> fginther: i see the same dependency error message on the ubuntu-touch-meta failed boottest
[18:27] <dobey> failing beause ubuntu-touch depends on a lib that had the abi changed due to gcc5 (that may not be migrated yet either)
[18:28] <dobey> though i don't know why it's not pulling them in from proposed pocket
[18:29] <dobey> since adt-run clearly has --apt-pocket=proposed :-/
[18:29] <fginther> dobey, that could also be the problem. There's a problem in that apt can't always figure out the right upgrade path... I'll try again once the new image proves to be installable.
[18:42] <dobey> ok
=== jhodapp|gym is now known as jhodapp
[19:19] <fginther> dobey, unity-scope-click is passing now. Will take another look at ubuntu-touch-meta next
[19:19] <dobey> fginther: ok, great. thanks.
[21:22] <cyphermox> awe_: NM is built and all in silo 15 if you want to test
[21:23] <awe_> cyphermox, ack
[21:33] <oSoMoN> ubuntu-qa: hey guys, I just marked silo 14 ready for QA validation, I’m hoping I can get an exception for this one to land it in OTA-6
[21:33] <alesage> oSoMoN, ack
[21:35] <oSoMoN> alesage, do I need to issue a special request for the exception?
[21:44] <alesage> oSoMoN, I don't think we govern that as QA
[21:44] <alesage> oSoMoN, or sorry--no I think we'll get to it
[21:45] <oSoMoN> cheers
[22:22] <awe_> cyphermox, all set testing; lgtm
[22:35] <tyhicks> ogra_: I'm heading out on vacation but the apparmor fix is going through our team's QA - track https://bugs.launchpad.net/apparmor/+bug/1484178 for updates
[22:35] <ubot5> Ubuntu bug 1484178 in apparmor (Ubuntu) "Policy cache file mtimes are not being set correctly" [Critical,Confirmed]
[22:37] <jdstrand> ogra_: I'll be handling the landing and I'm still on pause based on your earlier comment (not that I'm ready to push the button right now)