[00:00] <ToyKeeper> Woot, been waiting for that.
[00:01] <robru> ToyKeeper, ahh you're welcome
[00:02] <ToyKeeper> Oh, but this doesn't have a new mir?
[00:02] <ToyKeeper> D'oh.  I was mostly waiting for a new mir to test.  :)
[00:02] <robru> ToyKeeper, nope, this is specifically a big pile of changes before I land new mir ;-)
[00:02] <ToyKeeper> Okay.  r244 has had quite a few graphical issues which might be resolved by a mir update.
[00:03] <robru> ToyKeeper, yep, kgunn gave the green light on the mir update, I'm testing it myself right now, I just don't like any single image to have too updates because then it gets harder to bisect which change caused a problem.
[00:04] <robru> ToyKeeper, if you really are impatient, enable silo 18 and make sure the fixes really fix things ;-)
[00:14] <sergiusens> robru, I think silo 11 is ready for publishing; feel free to test it if you want https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=29
[00:15] <robru> sergiusens, thanks. how would I test that?
[00:16] <sergiusens> robru, so it just exposes something extra for ocide; oxide is not there yet; so just running the autopilots we have and making sure display isn't broken is enough
[00:17] <robru> sergiusens, ah ok. great. will publish it shortly (just testing mir now)
[00:21] <boiko> robru: please let me know when the silo is ready
[00:22] <robru> boiko, oops, forgot to ping you. did that way back when I said i was doing it ;-)
[00:23] <boiko> robru: nice! thanks! I will build the packages to start testing again tomorrow
[00:23] <robru> boiko, great
[00:25] <boiko> and with that I call it a day, see you!
[00:51] <thomi> doanac`: got a second?
[00:54] <thomi> veebers: doanac`: It doesn't look like the PPA is being added, the same issue we had with the gatekeeper job a while ago: http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/81/label=mako-07/console
[00:54] <thomi> if you search the console log for 'ci-train-ppa-service/landing-003'
[00:54] <thomi> I can't see the PPA ever being added
[00:54] <thomi> but perhaps one of you gents can see what I've missed
[00:55] <veebers> thomi: ugh :-\ perhaps the recent changes mean those details are echoed to log? (not sure, that's a long shot)
[00:55]  * veebers looks
[00:55] <thomi> I also couldn't see where the python-autopilot package was installed, which would allow us to compare the version numbers
[00:56] <veebers> thomi: I can see the ppa being added to "phablet-config writable-image" which wasn't happening last time (hence the change to specific revno)
[00:57] <thomi> veebers: right, I see that as well, but I don't think it's doing anything
[00:58] <veebers> thomi: I see similar output for phablet-config in the previous run (i.e. the version that worked)
[00:59] <thomi> hmmm
[00:59] <thomi> the previous version had plars' workaround
[01:00] <veebers> thomi: this run also has plars' work around, just updated code too. Doesn't searching for "Autopilot Package Version" give you the version?
[01:00] <veebers> Autopilot Package Version: 1.4+14.04.20140318-0ubuntu1
[01:00] <thomi> veebers: hmmm, ok
[01:01] <thomi> maybe it is working
[01:09] <imgbot> [01:12] <robru> woooot
[01:12] <robru> PUBLISH ALL THE THINGS! ;-)
[01:14] <robru> ToyKeeper, just published mir. next image build will be kicked by cron in about an hour
[01:22] <ToyKeeper> :)
[01:40] <robru> sergiusens, still around?
[01:40] <sergiusens> robru, was closing, anything urgent?
[01:40] <sergiusens> or that I need to look into?
[01:41] <robru> sergiusens, oh i was just wondering about silo 10, just happened to notice that the packages are from over a week ago.
[01:42] <robru> sergiusens, and it's the only silo that has packages older than a day ;-)
[01:42] <sergiusens> robru, oh, that's waiting for a gallery fix
[01:42] <sergiusens> robru, don't want to destroy it yet as it takes time to setup
[01:42] <robru> sergiusens, ok. we're down to 15 silos active, so I guess I don't need to jettison it after all, but I was kind of thinking "I wonder if I can jettison the oldest silo..."
[01:42] <robru> sergiusens, ok no worries
[01:42] <sergiusens> and it has the goodies the qa and ci team want
[01:43] <robru> ;-)
[01:43] <robru> sergiusens, good night!
[01:44] <sergiusens> good night!
[01:44] <sergiusens> well, not night for you just yet :-P
[01:44] <sergiusens> enjoy
[02:53]  * ToyKeeper wonders if that image is still happening any-minute-now, or if she should call r245 "it" for today
[02:55] <robru> ToyKeeper, should be starting within the next half hour as far as I know, but it does take 1hr usually to build them.
[02:57] <ToyKeeper> I can at least confirm that r245 didn't fix the mir screen update issues.
[02:58] <robru> ToyKeeper, no worries, wasn't expected to
[02:58] <robru> ToyKeeper, 246 is for you. mir is fully published and even the silo is cleaned, there's no way that image 246 can be kicked without it
[02:59] <ToyKeeper> No worries...  got a meeting now, and I'll check afterward.  :)
[03:04] <bregma> robru, silo landing-017 tested and ready for you to hit publish
[03:04] <robru> bregma, thanks, I might wait a couple hours on that. unity and mir in the same image would probably give didrocks a heart attack ;-)
[03:05] <robru> no wait
[03:05] <robru> unity7 ;-)
[03:05]  * robru has phones on the brain
[03:05] <bregma> it's the good kind
[03:05] <robru> bregma, ok, publishing
[03:05] <bregma> sweet, I might get to bed tonight after all
[03:06]  * bregma needs to adopt better work hygeine
[03:06] <robru> bregma, don't we all? ;-)
[03:06] <robru> bregma, ok, you are published.
[03:06] <robru> bregma, it's only 8PM for me, if you want to get some sleep I can merge & clean later
[03:07] <bregma> robru, sure, if you're not busy I'd appreciate it
[03:07] <robru> bregma, no worries
[03:21] <doanac`> thomi: looking at the job. i see this line: INFO:run-smoke:Running: /var/lib/jenkins/slaves/mako-07/workspace/autopilot-release-gatekeeper/label/mako-07/touch/scripts/provision.sh -i touch -p python-autopilot -p autopilot-touch -p libautopilot-qt -p libautopilot-gtk -p python-gi -p ubuntu-ui-toolkit-autopilot -p friends-app-autopilot -p mediaplayer-app-autopilot -p gallery-app-autopilot -p webbrowser-app-autopilot -p camera-app-a
[03:21] <doanac`> utopilot -p dialer-app-autopilot -p messaging-app-autopilot -p address-book-app-autopilot -p ubuntu-system-settings-online-accounts-autopilot -P ppa:ci-train-ppa-service/landing-003
[03:22] <doanac`> the -P ppa:.... indicates it gets added
[03:22] <thomi> doanac`: OK, I expected to see the output of add-apt-repository somewhere
[03:22] <thomi> doanac`: also, didn't it use to show when packages were installed?
[03:22] <doanac`> thomi: i think that happens in the "phablet-config" command. it probably just swallows that output unless it fails
[03:22] <thomi> as in, the output of 'apt-get dist-upgrade' ?
[03:22] <thomi> ahhh
[03:22] <thomi> OK
[03:23] <thomi> would it be difficult to add that?
[03:23] <doanac`> thomi: probably not. let me take a quick look at phablet-config
[03:26] <thomi> doanac`: It's not urgent, it looks like it's doing the correct thing, but it'd be nice to see the output of add-apt-repository and apt-get dist-upgrade
[03:26] <thomi> would make it much easier to confirm that it's working correctly
[03:26] <doanac`> thomi: i just jumped on the phone and confirmed apt had it configured
[03:26] <thomi> cool
[03:26] <doanac`> as per getting the output. i'm sure its easy to patch phablet-tools. to show the output.
[03:26] <thomi> we ended up comparing the version numbers
[03:27] <thomi> that would be awesome
[03:28] <doanac`> thomi: actually its a little annoying fixing it in phablet-tools based on my reading. not hard, but not trivial
[03:28] <doanac`> it might be easier to dump out that kind of information in that hook you use in your job
[03:28] <thomi> doanac`: ok, well, it's OK as it is I suppose :)
[03:30]  * doanac` goes to bed
[03:32] <bregma> robru, I'm still around so I'm doing my own merge & clean, but thanks for the offer
[03:32] <robru> bregma, oh ok, cool.
[04:09] <imgbot> [04:11] <robru> ToyKeeper, ^^ seems I mis-judged the time of the build by an hour, I guess some DST has thrown it off or something. Anyway it takes an hour to build so if you're still around an hour from now...
[04:12] <ToyKeeper> Yeah, I don't normally attempt sleep for at least another 4 hours.  :)
[04:13] <robru> excellent
[04:13] <rsalveti> no, sorry, my fault
[04:13] <rsalveti> had to disable cron as we built an image just a few hours ago
[04:13] <rsalveti> and wanted to make sure my livecdrootfs changes were good for next image
[04:13] <robru> rsalveti, ahhh, ok
[04:13] <rsalveti> sorry delaying it for 1 hour
[04:14] <ToyKeeper> I have *plenty* of other things to work on...  I'm not blocked at all.
[04:14] <robru> same, no worries
[04:16] <ToyKeeper> ... like a huge pile of tickets, or adding video encoding to my mirscreencast wrapper, or finishing a little UPay app to help with purchase support.
[05:19] <imgbot> [05:20] <robru> ToyKeeper, ^^^ ;-)
[05:24] <Mirv> hmm
[05:28] <Mirv> nice that "DONE" means "your device will update to it" too immediately
[06:23] <Wellark> morning!
[06:43] <ToyKeeper> flashy flashy
[07:11] <ToyKeeper> didrocks: You're just in time.  Image 246 landed and seems to fix the graphic freezes which plagued r244 and r245.
[07:11] <didrocks> ToyKeeper: excellent news \o/
[07:12] <didrocks> ToyKeeper: nothing worrying in the dogfooding side in 246?
[07:12] <didrocks> cihelp: no mako available though
[07:12] <ToyKeeper> Not yet, but I just started.
[07:12] <didrocks> ToyKeeper: great! thanks for the good news in the morning :)
[07:12] <ToyKeeper> (was waiting all day for a testable image)
[07:13] <didrocks> subprocess.CalledProcessError: Command '['bzr', 'checkout', '--lightweight', u'lp:ubuntu-calendar-app', '-r', u'201', 'work']' returned non-zero exit status 3
[07:13] <didrocks> humn, seems bzr didn't like
[07:13] <didrocks> let me try to restart mako
[07:14]  * didrocks wonders why some security tests failed
[07:22] <ToyKeeper> Hmm, that's odd.  My mako seems to have drained its battery even though it was plugged in.
[07:26] <didrocks> ToyKeeper: are you sure it was charging? Sometimes, the mako software (it's software) to charge can have races
[07:27] <ToyKeeper> Not sure.  I left it idle for a day or so, and found it so dead it couldn't even display the firmware's charging screen.
[07:27] <didrocks> yeah, was probably not "plugged" for the firmware's charging process
[07:28] <ToyKeeper> I've noticed, during use, that it can still decrease the overall charge level even while charging.
[07:29] <ToyKeeper> ... but then again, this unit was somewhat abused in a past life.  It was jfunk's, and I think he made a habit out of letting the battery drain completely.
[07:29] <ToyKeeper> Definitely not good for Li-Ion cells.
[07:32] <didrocks> right
[08:06] <Mirv> so, what about the test results this time for the newest images?
[08:06] <Mirv> I've been polling the new url
[08:07] <Mirv> I'd ping ci_help but I assume there won't be anyone around before the first vanguard wakes up
[08:08] <Mirv> didrocks: the sdk test should be fixed now btw
[08:08] <didrocks> Mirv: I've restarted the tests on the newest images
[08:08] <didrocks> as it was stuck
[08:08] <didrocks> seeing the sdk test passing, great!
[08:09] <didrocks> Mirv: the security ones are failing though, mind having a look?
[08:09] <didrocks> Mirv: and see if anything changed/entered the archive?
[08:10] <dbarth> good morning
[08:10] <dbarth> could i have a silo for line 13?
[08:11] <dbarth> (we landed silo 6 yesterday)
[08:11] <dbarth> those are quick bug fixes for the html5 sdk
[08:11] <sil2100> dbarth: looking
[08:11] <dbarth> sil2100: thanks
[08:12] <Mirv> didrocks: ok, great. aha, looking.
[08:16] <sil2100> didrocks: do I see correctly on the mir no-screen-refresh bug that it's fixed and released on 246? \o/
[08:17] <didrocks> sil2100: yeah, seems so! :)
[08:17] <didrocks> sil2100: there is only the unity-mir issue remaining, right?
[08:29] <dbarth> didrocks: hi, i understand that our unity-chromium-extension got stuck in proposed yesterday
[08:30] <dbarth> didrocks: do i need to pass a branch for that, or did robru unblock that already?
[08:31] <Mirv> oh.. so the results are back at the old place
[08:33] <Mirv> hmm, http://people.canonical.com/~ogra/touch-image-stats/20140318.2.changes (#245)
[08:36] <didrocks> dbarth: I do see it in the release pocket
[08:36] <didrocks> dbarth: so, all good :)
[08:36] <sil2100> dbarth: it's in release pocket, so I guess it's ok ;)
[08:38] <Mirv> so who in addition to jdstrand but perhaps closed to our timezones could understand what's going on in the security tests? a lot failures, but I fail to think of an update that could have caused it
[08:38] <Mirv> closer
[08:38] <Mirv> I also checked the tests themselves that they don't seem to have changed
[08:40] <sil2100> Mirv: did you try running them locally? I usually waited for jdstrand, not sure who else could take a look
[08:41] <dbarth> didrocks: ah cool;thanks
[08:41] <dbarth> and thanks for the silo
[08:41] <sil2100> yw :)
[08:41] <didrocks> would be nice to do our first investigatoin
[08:41] <didrocks> as his code didn't change apparently from Mirv's link
[08:42] <sil2100> Mirv, didrocks: but on the previous image it was also failing
[08:43] <sil2100> Ah, no change
[08:43] <sil2100> Nevermind then
[08:48] <Mirv> sil2100: trying to...
[09:05] <seb128> hum, why is landing-007 stating "building" when the ppa is done building since yesterday evening
[09:05] <seb128> oh, hey there btw ;-)
[09:08] <mhr3> ehm, why can't i get anything from system-image.ubuntu.com?
[09:08] <sil2100> Hey
[09:09] <sil2100> seb128: looking
[09:09] <seb128> sil2100, hey, thanks
[09:11] <sil2100> seb128: interesting - it seems citrain did not register any 'build' operation for the current silo, I wonder how the package appeared in the PPA
[09:13] <sil2100> seb128: not really sure what happened, but I guess we can simply fix it by re-running build - maybe even with watch-only
[09:13] <didrocks> jenkins went down
[09:14] <didrocks> tonight
[09:14] <didrocks> so it can be while this was running
[09:14] <sil2100> Ah, makes sense
[09:14] <didrocks> and jenkins forgot about the job once restarted
[09:14] <didrocks> (but dput could have already been proceeded)
[09:15] <seb128> sil2100, didrocks: can you do whatever you think is right to it?
[09:15] <seb128> e.g trigger a rebuild, or watch only rebuild, or...?
[09:16] <didrocks> I thought sil2100 was going to relaunch with watch only
[09:16] <sil2100> Will do that, thought the lander will do it ;) But I will
[09:17] <Mirv> I can reproduce at least the ./click-apparmor 2 failures
[09:17] <sil2100> seb128: all is cool now
[09:17] <seb128> sil2100, well, cjwatson started those build and I'm not sure if he's around yet, so we can as well keep things moving meanwhile
[09:17] <seb128> sil2100, thanks
[09:18] <didrocks> Mirv: if the code doesn't make sense to you, you can probably bisect the component that were upgraded
[09:18] <sil2100> Mirv: :<
[09:18] <didrocks> as we know at which image it started from
[09:19] <Mirv> yes, the list is just quite.. interesting http://people.canonical.com/~ogra/touch-image-stats/20140318.2.changes
[09:19] <Mirv> I wouldn't be surprised to find that downgrading doesn't help, but we'll see
[09:21] <Mirv> hmm, although I have "start: command not found"
[09:22] <didrocks> Mirv: but you can reproduce locally, right?
[09:23] <didrocks> Checking aa-exec-click ... !FAIL!
[09:24] <didrocks> I would start with that
[09:24] <ogra_> ToyKeeper, did you push your pictures via mtp ?
[09:24] <ogra_> (it should run as the phablet user)
[09:26] <Mirv> didrocks: no, I thought I could since I had the same number of failures. but I had aa-exec-click passing while two "Checking application upstart job":s failing
[09:26] <ToyKeeper> ogra_: No, I just 'adb push'ed them as a tarball, then unpacked.  What's weird is that the script did a chown phablet.phablet on all the files afterward (and the dir itself ended up with the wrong owner somehow).
[09:26] <ogra_> aha
[09:26] <Mirv> I'm seeing now how apparmor-easyprof-ubuntu while preparing to downgrade packages
[09:26] <didrocks> Mirv: yeah, the infrastructure could have changed as well maybe
[09:26] <ogra_> ToyKeeper, well, for adb thats the right owner since we run it as a root shell by default :)
[09:27] <ogra_> you need to take extra steps when using is
[09:27] <ogra_> *it
[09:27] <ToyKeeper> It wasn't root.root though, and it actually changed back to system.system a few times after I manually chown'd it to phablet.
[09:27] <ogra_> yes, adb is evil :)
[09:28] <ogra_> it also removes all executable bits from files (in case you copy some binaries in the future, you need to make them executable again)
[09:28] <ToyKeeper> Hmm, I haven't found that to be the case.
[09:28] <ogra_> or "official" way of tranferring data is mtp
[09:29] <ToyKeeper> I routinely 'adb push mirshot.py /home/phablet' and it's still executable afterward.
[09:29] <ogra_> intresting
[09:29] <ogra_> i always end up with non executable binaries when i do that
[09:29] <ToyKeeper> It's root.root, as expected, but it's mode 777.
[09:30] <ogra_> bug 1204925
[09:30] <bzoltan> ogra_: sil2100: didrocks: do you know who to go to with Jenkins autobuild issues? I see that MRs from outside of the team are not triggering Jenkins build.
[09:30] <ogra_> hmm, might only be the case when you pull from the device
[09:30] <ToyKeeper> What I found particularly odd was that Gallery refused to show anything, even though the dir and all its contents were readable.
[09:30] <ogra_> bzoltan, see backlog
[09:30] <ogra_> bzoltan, jenkins outage
[09:30] <didrocks> bzoltan: it's the CI team
[09:31] <didrocks> ogra_: he's talking about another jenkins
[09:31] <ogra_> oh ok
[09:31] <ogra_> ETOOMANYJENKINS
[09:31] <ogra_> :P
[09:31] <didrocks> +1 :p
[09:31] <ogra_> didrocks, bah, still no HO link ... the location hasnt worked either
[09:32] <didrocks> ogra_: yeah, see! :p
[09:32] <ogra_> i though it was a clever hack :P
[09:33] <Mirv> didrocks: sil2100: just a quick update for the meeting - so far no failures in apparmor-easyprof-ubuntu, even though 118 failures on test infrastructure including right in the beginning. it's still running.
[09:34] <ToyKeeper> I'm glad to see some libc error code humor.  I have a bad habit of proclaiming "ENOENT!" when I look for something and can't find it.
[09:35] <ToyKeeper> People get the joke a lot more often if phrased using a different standard though...  "404 pizza not found"
[09:35] <ogra_> haha
[09:48] <cjwatson> sil2100,seb128: right, jenkins was waiting for 007 to build when it crashed
[09:48] <cjwatson> thanks for poking that
[09:49] <seb128> cjwatson, yw!
[09:49] <sil2100> cjwatson: np :)
[09:50] <cjwatson> publishing that since seb128 tested it last night
[09:50] <seb128> confirmed, works fine on my n4
[09:51] <sil2100> o/
[09:54] <davmor2> popey: search on music lens is it crashing for you still?
[09:54] <popey> "still"?
[09:54] <popey> implying it always did?
[09:55] <davmor2> popey: I'm seeing it now but I thought you had seen it before
[09:55] <popey> nope
[09:55] <popey> never tried it, ever
[09:55] <popey> but yes, i get a unity8 crash when searching in the dash
[09:55] <popey> s/dash/music/
[09:56] <cking> hey, the desktop boot speed tests seem to be totally bogus because of blocking waits on utah-done.py, see https://jenkins.qa.ubuntu.com/job/bootspeed-trusty-desktop-amd64-acer-veriton-01/98/artifact/11/bootchart.png  - can somebody fix this?
[09:57] <jibel> nuclearbob, ^^
[09:59] <cking> i would have reported this earlier, but the graphs have been broken for *months*
[09:59] <apw> cking, that looks like something logging in every 5s and consuming like 2-3 seconds of cpu each time, winner
[09:59] <cking> something very utah and very wrong then
[10:02] <tsdgeos> guys, who do i have to bribe so we get timestamps in the logs of https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/1420/consoleFull like the ones at http://build.kde.org/job/kde-runtime_oldstable/7/consoleFull ?
[10:03] <cking> perhaps I'll file an issue report in asana too
[10:04] <Mirv> psivaa: sil2100: so just FYI I ran apparmor-easyprof-ubuntu manually on #246 and had 0 failures where as http://ci.ubuntu.com/smokeng/trusty/touch/mako/246:20140319.2:20140304/7259/security/ shows 118 failures...
[10:04] <jibel> tsdgeos, you have to bribe the CI team to install the timestamper plugin in jenkins
[10:05] <Mirv> Passed:  1381/1381
[10:05] <tsdgeos> jibel: and who would be in that team?
[10:06] <psivaa> Mirv: ok, could be something ci specific. i'm going through the logs now there
[10:06] <jibel> vila, ^^ see tsdgeos request for you
[10:12] <vila> tsdgeos: rather than adding a plugin (which has issues), can you use annotate_output for that job ?
[10:13] <tsdgeos> vila: what is annotate_output?
[10:14] <vila> tsdgeos: sorry, annotate-output: annotate program output with time and stream
[10:14] <tsdgeos> vila: still no idea of what you're suggesting :) what is "annotate-output"? an option of the job?
[10:14] <vila> tsdgeos: it's part of the devscripts  package so probably available everywhere you need it
[10:15] <tsdgeos> vila: ah you mean running my program with annotate-output?
[10:15] <vila> tsdgeos: yes
[10:15] <tsdgeos> vila: what's the issues the plugin has?
[10:16] <vila> tsdgeos: not that on in particular, we have issues maintaining plugins with jenkins in general
[10:16] <vila> s/on/one/
[10:16] <tsdgeos> ok
[10:16] <vila> tsdgeos: so we try to limit their use and preferably not add new ones while we try to get rid of them ;)
[10:22] <ogra_> didrocks, FYI http://people.canonical.com/~ogra/touch-image-stats/246.changes .... the bot should now set changelog links after the build is done (and announce them here with the "DONE" message) so we dont need to dig through cdimage build ids anymore
[10:23] <didrocks> ogra_: great!
[10:26] <cjwatson> OK, so what drugs exactly is qmake on?
[10:26] <cjwatson> https://launchpadlibrarian.net/169947029/buildlog_ubuntu-trusty-ppc64el.ubuntu-download-manager_0.3%2B14.04.20140317-0ubuntu1_FAILEDTOBUILD.txt.gz
[10:27] <cjwatson> search for arm-linux-gnueabihf, and notice the architecture
[10:27] <cjwatson> Mirv: ^-
[10:28] <Mirv> fun fun
[10:29] <Mirv> I'm sure on non-prescribed ones
[10:31] <cjwatson> no mention of arm-linux-gnueabihf in the qtbase build log
[10:31] <Wellark> Multiple images were produced:
[10:31] <Wellark> #241:
[10:31] <Wellark> - got the unity8 locking screen/hud removal revert fix in.
[10:31] <Wellark> what does "hud removal" mean?
[10:32] <Wellark> Saviq: ^
[10:33] <vila> Saviq: ping, I'm looking at bug #1294233  but it seems I can't reproduce ? O_o
[10:33] <Saviq> Wellark, we're dropping it from the bottom edge, pending design for a new place for it
[10:34] <Saviq> vila, maybe someone touched the file I mentioned already?
[10:34] <Wellark> Saviq: is there a bug to track that pending design?
[10:34] <Saviq> Wellark, not that I know of
[10:34] <cjwatson> Mirv: oh, sorry, this isn't qmake's fault really, ubuntu-download-manager has a crazy .pri
[10:34] <vila> Saviq: well, no, I'm supposed to do that ;) So I was wondering if a different fix was applied...
[10:34] <Wellark> Saviq: well, how do we track it then and get designers to work on it?
[10:35] <Saviq> Wellark, they are being gotten to work on it without our intervention
[10:35] <Wellark> Saviq: who is working on that?
[10:36] <Saviq> Wellark, bearing in mind our limited design resources it's probably on the backlog
[10:37] <Wellark> Saviq: so no way of invoking the hud anymore and no ETA on when we get it back then
[10:37] <Saviq> Wellark, yes
[10:37] <Wellark> well, given the amount of time me, ted, pete and marcus have put into that I find the situation unfortunate
[10:37] <Saviq> vila, not that I know of, https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/3533/ is the last unstable job ran
[10:37] <Saviq> vila, and it still has the overlay on
[10:38] <vila> Saviq: http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/3541/
[10:38] <Wellark> and no bug to track the progress of design
[10:38] <Wellark> I will file one then.
[10:38] <Mirv> cjwatson: ok, that's at least good news. I was thinking that even with our large CMake usage we probably must have had succeeded qmake builds too.
[10:38] <Saviq> vila, oh well, yeah, I said on the bug that I can't confirm that's actually affecting the results
[10:38] <Mirv> hmm, where did sil2100 go
[10:38] <Saviq> vila, but still needs to go to not mess with the video output
[10:39] <cjwatson> Mirv: http://bazaar.launchpad.net/~ubuntuone-hackers/ubuntu-download-manager/trunk/view/head:/common-project-config.pri
[10:39] <vila> Saviq: oh, "might"
[10:39] <cjwatson> Mirv: you may be ill now
[10:39] <Saviq> vila, you need a failing test to get the video :)
[10:39] <vila> Saviq: ack, so it may not be reproducible and still need to be fixed, ack, too bad it can't be reproduced reliably then :-/
[10:39] <cjwatson> Mirv: I'm just going to hit it with dh_auto_configure -- LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) unless you have a better idea
[10:39] <vila> Saviq: yeah, got that
[10:40] <vila> Saviq: just to be sure, the file only has to exist right ? No content is needed correct ?
[10:40] <Saviq> vila, yeah, just touch it
[10:40] <Mirv> cjwatson: sounds good enough
[10:44] <vila> Saviq: fixed, let me know if the issue comes back, since it can be reproduced at will, it's hard to ensure it's really fixed :-/
[10:44] <Wellark> Saviq: what happened to the zero regression policy?
[10:44] <Wellark> does not apply to design?
[10:45] <cjwatson> mandel: do you think we could land https://code.launchpad.net/~cjwatson/ubuntu-download-manager/fix-libdir/+merge/211699 fairly quickly assuming it passes CI?  it's blocking some other packages in -proposed
[10:46] <cjwatson> seb128: ^- in case you were wondering why things are still stuck
[10:48] <ogra_> Wellark, well, even with zero regression you have to make compromises if parts of the system change and others are not ready for that change ... else we would have to block landings forever
[10:51] <Saviq> vila, will do
[10:51] <Saviq> Wellark, depends on what you consider a regression
[10:51] <Saviq> Wellark, getting the most confusing (for users) thing out of the way is probably not one
[10:53] <seb128> cjwatson, thanks
[10:54] <didrocks> ogra_: do you mind looking at system settling? It's not the first time we see that
[10:59] <didrocks> (shorts_app/filemanager)
[11:02] <ogra_> didrocks, once i got the top logs yep
[11:03] <didrocks> thanks
[11:07] <didrocks> psivaa: Mirv: did you get anywhere with the security tests that we'll be able to hand over jdstrand?
[11:08] <psivaa> didrocks: still looking.. the unity-scope-loader crash has not occurred with 246 :/
[11:08] <didrocks> ok, so wrong lead…
[11:08] <psivaa> didrocks: curious if 'util-linux from 2.20.1-5.1ubuntu16 to 2.20.1-5.1ubuntu17' on image 245 has any connections.. but Mirv dint see the failures in 246
[11:09] <sil2100> hmm
[11:10] <Mirv> psivaa: indeed, I was preparing to downgrade it but I was not able to get the failures
[11:11] <didrocks> psivaa: no, doesn't seems to be linked: http://launchpadlibrarian.net/169934738/util-linux_2.20.1-5.1ubuntu16_2.20.1-5.1ubuntu17.diff.gz
[11:13] <psivaa> didrocks: Mirv: ok, looks like we need to ping jdstrand for this
[11:14] <psivaa> i am digging further btw
[11:14] <didrocks> thanks psivaa
[11:14] <psivaa> yw :)
[11:15] <davmor2> morning all
[11:16] <psivaa> Mirv: btw, curious which user you ran the tests as?
[11:16] <vila> davmor2: woke up twice today ?
[11:16] <davmor2> vila: no this is me officially at work so I say morning on the important channels so people know I'm about :)
[11:17] <vila> davmor2: :)
[11:27] <mandel> cjwatson, sure, let me take a quick look
[11:28] <mandel> cjwatson, done
[11:30] <cjwatson> mandel: oh, in a silo already?
[11:31] <mandel> cjohnston, oh, not in a silo, but I have a silo for udm and we can ask segio to add it to silo 15
[11:34] <Mirv> psivaa: as phablet (su - phablet)
[11:35] <psivaa> Mirv: ok, that's what the tests in ci run as too :/
[11:35] <seb128> sil2100, Mirv: I appreciate that touch fixes are important but desktop work, if you could assign the "desktop only" lines in there rather than skipping over them to assign touch ones that came after that would be nice :-)
[11:36]  * sil2100 didn't assign any silos right now
[11:36] <cjwatson> ok, click in silo 8 looks good, publishing
[11:37] <sil2100> seb128: those two were assigned by Mirv - and besides, we don't assign any more silos right now as we are more or less ful
[11:37] <sil2100> *full
[11:37] <seb128> sil2100, shrug, ok, I'm not freeing any of my silo in protestation then :p
[11:38] <sil2100> No no no ;)
[11:38] <sil2100> I guess I'll assign one of them at least, since a buffer of 3 seems to be still sane
[11:38] <seb128> thanks
[11:38] <seb128> I've 2 that are going through publishing
[11:38] <seb128> so those can come back to the pool soon
[11:39] <ogra_> and done forget the towel :)
[11:39] <ogra_> *don't
[11:39] <seb128> ;-)
[11:46] <mandel> cjwatson, will try to add it to silo 15, if not, will do a merge with one of the branches in that silo, does that sound good?
[11:48] <cjwatson> thanks
[11:49] <cjwatson> mandel: I don't think you can mean 15, though, that has gallery-app in it
[11:49] <mandel> cjwatson, sorry, one off error
[11:49] <mandel> cjwatson, 14 (i though it was 15)
[11:50] <mandel> cjwatson, we will at it to that silo, I'm testing it at the moment, so will trigger a rebuild, retest it and land it
[11:50] <mandel> hopefully in an hour or so we will be done
[11:50] <cjwatson> cool
[11:51] <Mirv> sil2100: seb128: hi, I did assign only 1 after freeing 1. I'm sometimes a bit afraid still of assigning silos if I'm not specifically asked, even if it says "Yes" in the ready column, so that's why today I didn't assign silos for the new ones
[11:51] <Mirv> I didn't assign the last line, but I did snatch one for qtwebkit since it'll take ages to build
[11:52] <sil2100> Mirv: ACK ;) Better safe than sorry!
[11:53] <didrocks> well, don't get too much in the habit of getting pinged, it's not scalable
[11:53] <didrocks> I think we should show that we respond/assign silos when all infos are set
[11:53] <didrocks> and look at that regularly
[11:53] <didrocks> I did assign the unity8 one as per #ubuntu-unity as it's a blocker fix
[11:54] <didrocks> (the volume key)
[12:01] <seb128> Mirv, k, I can ping more directly if you want ;-)
[12:04] <Mirv> seb128: I'll go with Didier's "being responsive" method :)
[12:05] <Mirv> now we're at 18/20 full again though
[12:06] <Mirv> three should become available ~soon
[12:07] <seb128> Mirv, I'm cleaning 011
[12:11] <sil2100> seb128: \o/
[12:11] <sil2100> seb128: I'll assign a silo for you then once that's free
[12:12] <seb128> you can nag Laney about landing001
[12:12] <Laney> little ol' me
[12:13] <Laney> waiting for new cmake to check it end to end
[12:19] <Mirv> sil2100: it's free now
[12:23] <sil2100> Mirv: thanks! :)
[12:26] <ogra_> didrocks, so looking at the settle stuff i see two things that show up in nearly every sample ... one is usc and the other is mpdecision ... mpdecision is the android process caring for offlinig/onlining CPU cores and for handling the CPUfreq governor dynamically ... i know that rsalveti is looking into an issue wheer a wakelog is held on the mako ... thats probably related
[12:26] <popey> cprov: https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily - stock ticker mobile app is missing for trusty, any idea why?
[12:27] <didrocks> ogra_: ah, interesting :)
[12:27] <didrocks> ogra_: is there a bug for it?
[12:27] <cprov> popey: no, but I can check.
[12:27] <popey> thanks
[12:27] <ogra_> didrocks, but looking at the top logs there isnt really a single process hogging the CPU (its just that the two above constantly consume ~1% together, but that woouldnt really cause the settle test to fail)
[12:27] <cjwatson> popey: because it was never uploaded there?
[12:27] <cjwatson> https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily/+packages?field.name_filter=stock-ticker-mobile-app&field.status_filter=&field.series_filter=
[12:28] <ogra_> didrocks, not sure if there is a bug for it, lets wait for rsalveti
[12:28] <popey> cjwatson: well, my question is more - why are all the others there and that one isnt
[12:28] <cjwatson> popey: my question is why this is a Launchpad problem
[12:28] <popey> dont think i said it was a lp problem
[12:28] <popey> more of a jenkins one i suspect
[12:28] <didrocks> ogra_: ok ;)
[12:28] <cjwatson> ok, I assumed that since you were asking an LP dev :)
[12:29] <popey> cjwatson: asking the vanguard rather than directly pinging fgin ther as i would normally ☻
[12:29] <cprov> cjwatson: I am also CI vanguard ...
[12:29] <cjwatson> oh right
[12:29]  * cjwatson butts out then
[12:29] <popey> you butt as always is welcome.
[12:29] <cjwatson> fnar
[12:29] <ogra_> didrocks, and i wouldnt blame these two, i just see them iin top frequently ... there are random processes in each sample that consume more at times
[12:29] <didrocks> ogra_: ok, sounds "good" then :)
[12:29] <ogra_> heh
[12:30] <ogra_> well, i would really like to have some more reliable log that can point to one particular process
[12:30] <didrocks> yeah
[12:30] <ogra_> top is really random :(
[12:31] <didrocks> ogra_: not sure who wrote that dumb test
[12:31] <didrocks> oh wait! :)
[12:31] <ogra_> haha
[12:31] <ogra_> i reallly think 97.5% are to strict ... 95 would be better
[12:32] <didrocks> yep
[12:32] <didrocks> it's in the "noise" level
[12:36] <ogra_> well, its also quite wridly disconnected
[12:36] <ogra_> if you look at http://ci.ubuntu.com/smokeng/trusty/touch/mako/246:20140319.2:20140304/7259/ubuntu_filemanager_app/922972/
[12:36] <ogra_> it talks about something like 87%
[12:36] <ogra_> but the topafter.log doesnt even have such values
[12:37] <ogra_> topafter jumps between 99 and 75 or some such, being most of the time around 95
[12:39]  * didrocks wonders if vmstat shouldn't be used rather
[12:39] <didrocks> IIRC, vmstat uses an integral if you space the measures
[12:39] <didrocks> so you end up with an average value
[12:41] <ogra_> i think the actual test itself uses vmstat now
[12:42] <didrocks> ah, so the only issue would be to "know" which process history-wise took what amount of CPU
[12:43] <ogra_> right, but when you capture that *during* the test you taint the test result
[12:44] <ogra_> because your capturing uses resources
[12:45] <didrocks> well, Schrödinger FTW of course, but we have to find a way in the platform-leve anyway
[12:46] <didrocks> level*
[12:46] <didrocks> ogra_: not sure if you noticed, but dialer-app crashed
[12:46] <didrocks> so yeah, it was *that* run
[12:47] <ogra_> huh ?
[12:47] <didrocks> in dialer-app test
[12:47] <ogra_> it always did that
[12:47] <ogra_> since months
[12:48] <didrocks> yeah, but remember the discussion during the meeting?
[12:48] <didrocks> we didn't get the crash :)
[12:48] <nuclearbob> cking jibel: I'll take a look at the bootspeed issue.  Would it be better to disable the jobs in the interim, or let them keep running while it's being fixed?
[12:48] <didrocks> on image -1
[12:48] <ogra_> right, so we didnt get it one time oout of 50 :P
[12:48] <ogra_> lucky people we are :P
[12:49] <cking> nuclearbob, i guess keep them running as we can still see if other parts of the system (e.g.kernel) are regressing
[12:50] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/238.changes ... that was the last dialer-app change and it didnt fix the crash
[12:50] <nuclearbob> cking: okay.  I've got an idea for a fix that I can test today, thanks for pointing out the problem
[12:51] <cking> nuclearbob, thanks for responding to it so quickly, much appreciated
[12:58] <cprov> popey: I have more info on the missing stock-ticker for trusty.
[12:58] <popey> super
[12:58] <cprov> popey: this app job has been triggered manually in the past (by sergiusens), last time it run was 4 months ago.
[12:59] <popey> cprov: oh, i thought it was all automagical.
[12:59] <popey> cprov: is that the case for all the core apps? if so, can we auto-magical-ise it?
[12:59] <sergiusens> popey, what are we talking about?
[12:59] <popey> sergiusens: stock-ticker-mobile-app in core apps daily ppa missing trusty build
[12:59] <cprov> popey: yes, me to, but it depends on setting a timer trigger up
[13:00] <sergiusens> popey, oh, I don't do debs anymore (for apps ;-) )
[13:00] <sergiusens> as in, I haven't dealt with the infra for that in over a year; that's fginther 's turf
[13:01] <mhr3> sil2100, silo for #51 pls?
[13:01] <popey> cprov: can we do a one time trigger and then look at automagic longer term?
[13:02] <cprov> popey: anyway, could you please file a bug on ubuntu-ci-services-itself requesting the setup for stock-ticker?
[13:02] <popey> sure
[13:03] <popey> done, bug 1294640
[13:05] <cprov> popey: thanks, I will point fginther to it. How urgent is it for you ?
[13:09] <popey> cprov: low to medium
[13:09] <popey> cprov: for now I'll just copy-package from saucy to trusty to test
[13:12] <cprov> popey: good idea, let me know how it goes.
[13:14] <sil2100> mhr3: looking!
[13:14] <sil2100> mhr3: need to check how many free silos we have ;)
[13:14] <sil2100> mhr3: ok, we'll have to wait, we're currently low on silos
[13:15] <sil2100> mhr3: but I see one silo is freeing right now, so I should be able to assign you one in some moments
[13:16] <psivaa> didrocks: still no luck with the security failures. reverting suspicious pkges from (20140318.2) dint solve the issue.
[13:16] <psivaa> jdstrand: would you mind taking a look at security test failures?
[13:16] <didrocks> psivaa: ok, can be infra test environment I guess
[13:16] <psivaa> jdstrand: http://paste.ubuntu.com/7119715/ is the kern.log
[13:17] <psivaa> jdstrand: http://paste.ubuntu.com/7119720/ is the auth.log when the tests were running if that helps
[13:20] <psivaa> didrocks: yea, i can not rule that out.. but this testing does not look too much dependent on the infra but not really sure :)
[13:20] <didrocks> let's see
[13:20] <mandel> sergiusens, cjwatson silo 14 looks good after testing updates + click scope and manual downloads via dbus, +1 to land it
[13:20] <mhr3> sil2100, ty
[13:21] <sergiusens> sil2100, can you push publish on silo 14?
[13:26] <sil2100> sergiusens: ok, looking now
[13:28] <cjwatson> mandel: great
[13:28] <cjwatson> sil2100: 8 should be free
[13:39] <jdstrand> psivaa: ack
[13:40] <jdstrand> psivaa: where is the test output?
[13:41] <psivaa> jdstrand: 1 sec pls
[13:42] <jdstrand> psivaa: I see it
[13:42] <jdstrand> aa-exec-click is failing
[13:43] <jdstrand> hmm
[13:43] <jdstrand> psivaa: do you have access to the test environment?
[13:43] <psivaa> jdstrand: these tests are run from the host via adb
[13:43] <psivaa> jdstrand: yes
[13:44] <jdstrand> psivaa: what is the output of 'ls -la /tmp/.X11-unix' ?
[13:45] <psivaa> jdstrand: http://pastebin.ubuntu.com/7119855/
[13:45] <jdstrand> right, that is the problem I think. let me see
[13:46] <jdstrand> psivaa: why does that file exist btw?
[13:46] <jdstrand> psivaa: this is on the device with mir, no?
[13:46] <ogra_> jdstrand, because ofono-phonesim creates it via its deps and it never gets uninstalled once it is not needed anymore
[13:46] <jdstrand> I see
[13:47] <psivaa> jdstrand: ahh there was a ofono-phonesim update on that changelist
[13:47] <ogra_> we have asked for removing it (and its deps) when it is not needed but i think nobody had time yet to add that code
[13:47] <psivaa> in fact it's ofono and ofono-scripts
[13:48] <psivaa> jdstrand: do you want me to remove that file, revert ofono and try the tests again?
[13:48] <ogra_> i.e. ofono-phonesim should only be installed prior dialer-app and messaging-app tests ... and should be purged along with its deps completely once these tests have finished
[13:48] <jdstrand> psivaa: just remove the file and run the click-apparmor test. it will pass, I'm quite sure
[13:49] <psivaa> jdstrand: ack, let me try
[13:49] <ogra_> psivaa, neither ofono nor ofono-scripts will install the X11 virtual frambuffer package ... that comes from ofono-phonesim
[13:49] <dbarth> sil2100: hey, so i've fixed the MP set on line 11; we're ready for a new landing attempt
[13:49] <jdstrand> didrocks: fyi, the security test failure is understood. imho it should not block promotion, but it isn't clear where we will fix it
[13:49] <didrocks> jdstrand: ok, no user facing issue?
[13:49] <jdstrand> no, not at all
[13:50] <didrocks> jdstrand: can you just log a bug? I'll mention it but in the non blocker list
[13:50] <jdstrand> it is aa-exec-click doing its job, but thinking X is running
[13:50] <jdstrand> aa-exec-click isn't used on touch
[13:50] <ogra_> which is true
[13:50] <didrocks> interesting ;)
[13:50] <ogra_> since ofono-phonesim installs xvfb and it is kept during the full test cycle
[13:51] <didrocks> oh
[13:51] <didrocks> ok :)
[13:51] <didrocks> thanks, no backlogging required!
[13:51] <sil2100> dbarth: so, need a reconfigure?
[13:51] <ogra_> you could forcefulls apt-get purge xfvb at the start of your test ;)
[13:51] <ogra_> until we get that properly fixed
[13:52] <Mirv> dbarth: sil2100: you'll need a new silo, but again only 3 free
[13:52] <jdstrand> so, as I see it, we can either a) make sure that these packages aren't installed, b) update the click-apparmor and apparmor-easyprof-ubuntu tests to pass -x to aa-exec-click or c) come up with another method to see if running under X
[13:52] <jdstrand> 'c' may not matter if 'a' isn't fixed
[13:52] <ogra_> a is the proper fix
[13:53] <ogra_> just needs some free developer time in QA/CI
[13:53] <ogra_> which we dont seem to have
[13:54] <sil2100> dbarth: as Mirv said, we'll have to wait a bit
[13:54] <jdstrand> I think I can do 'b', but add another single test to verify aa-exec-click under X dtrt
[13:54] <jdstrand> I'll do that. it won't take long at all
[13:55] <jdstrand> feel free to do 'a' still though. seems it could cause other side-effects
[13:55] <ogra_> it does
[13:55] <cjwatson> sil2100: silo 14 doesn't seem to be publishing (per sergiusens half an hour ago)?
[13:56] <sil2100> cjwatson: I'm testing it on my device right now
[13:56] <sil2100> cjwatson: we are double-testing everything now before publishing
[13:56] <cjwatson> oh, ok
[13:57] <psivaa> ogra_: ok, of the file only comes form ofono-phonesim.. still dont know how that comes from image 245 where there is no change to ofono-phonesim
[13:57] <dbarth> sil2100: ok, waiting; we'll push our other silo inthe meantime
[13:57] <psivaa> s/of/if
[13:57] <ogra_> psivaa, probably the test that installs ofono-phonesim did run before security this time
[13:57] <ogra_> while it doesnt in other runs
[13:58] <psivaa> ogra_: no, i was testing only the security tests noting else on  fresh install
[13:59] <ogra_> hmm, then i dont get how you get the /tmp/.X11-unix socket at all
[13:59] <ogra_> for this to exist there must be an xserver running
[13:59] <jdstrand> which is quite odd :)
[14:00] <ogra_> hrm
[14:00] <ogra_> root@ubuntu-phablet:/# ls -la /tmp/.X11-unix/
[14:00] <ogra_> total 0
[14:00] <ogra_> drwxrwxrwt 2 root root  40 Mar 19 12:13 .
[14:00] <ogra_> drwxrwxrwt 6 root root 300 Mar 19 13:17 ..
[14:00] <didrocks> kgunn: hey, thanks for the fix, but I notice that https://wiki.ubuntu.com/Process/Merges/TestPlans/Mir doesn't have manual testing for the regressions you didn't automate, or did you add automated tests for those to not happen again?
[14:00] <ogra_> where the heck does that come from on a fresh install
[14:00] <didrocks> kgunn: remember the email + the direct IRC ping :)
[14:01] <ogra_> didrocks, it might actually be something else than xvfb here ... i see the .X11-unix socket dir on a fresh bootstrap install
[14:02] <jdstrand> didrocks: fyi, bug #1294667
[14:02] <didrocks> thanks jdstrand
[14:02] <jdstrand> didrocks: this won't be fixed in a package upload, so I'll just ping you when done
[14:03] <didrocks> jdstrand: fine with me :)
[14:03] <jdstrand> ogra_: so, I think /tmp/.X11-unix existing is 'normal'. It having files in it is not
[14:03] <ogra_> jdstrand, why would existing be normal ?
[14:03] <jdstrand> ogra_: but maybe /tmp/.X11-unix existing at all shouldn't be considered normal
[14:03] <ogra_> we dont have any X11 stuff by default
[14:03] <sergiusens> sil2100, your team retest or do you require two people to test?
[14:04]  * ogra_ purges ofono from his test device
[14:04] <jdstrand> ogra_: right-- I put in in quotes because it is odd, but I observed this behavior before (in fact, I had to adjust the aa-exec-click check to look in /tmp/.X11-unix if it exists cause it did exist on my device)
[14:04] <ogra_> i really dont think it is ofono
[14:05] <ogra_> i definitely have no sockets inside ... but it also shouldnt exist
[14:05] <sergiusens> ogra_, the latest ofono initializes unintialized vars and adds s/python-dbus/python3-dbus/ for ofono-scripts
[14:05] <jdstrand> that is what I thought
[14:05] <jdstrand> but it did
[14:05] <ogra_> sergiusens, but no dbus-x11
[14:05] <ogra_> so that dir should still not exist
[14:05] <jdstrand> it doesn't on my r237 right now, let me check a newer image
[14:06] <cjwatson> /etc/init.d/x11-common exists
[14:06] <sergiusens> ogra_, no; unless it's brought in by python3-dbus, but afaik, that dep should of been installed by something else already
[14:06] <cjwatson> that'll be creating it
[14:06] <ogra_> ah
[14:06] <jdstrand> 240 has it
[14:06] <ogra_> right, even after purgig ofono i have it
[14:07] <cjwatson> http://paste.ubuntu.com/7119953/
[14:07] <cjwatson> so that'll probably take some effort to unwind
[14:07] <cjwatson> (that's not a very helpful log, I suppose)
[14:07] <ogra_> yeah, gsd/usd are needed
[14:07]  * jdstrand is continuing to adjust the security tests to not suffer from the side-effect
[14:08] <ogra_> i doubt we use xklavier atm
[14:08] <kgunn> didrocks: updated https://wiki.ubuntu.com/Process/Merges/TestPlans/Mir
[14:08] <sergiusens> ogra_, it's the new qt is my latest bet
[14:08] <cjwatson> like I say, not a helpful log, please don't get distracted by the details of it
[14:08] <sergiusens> ogra_, libqt5gui5:armhf depends on libice6 (>= 1:1.0.0) -> libice6:armhf depends on x11-common
[14:08] <cjwatson> what happens is that apt tries to put other things in place to cope with whatever's torn out by x11-common and then gets horrendously confused
[14:08] <ogra_> sergiusens, aha
[14:09] <ogra_> well, i dont think the dir does any harm ... its just ugly
[14:09] <jdstrand> though, it is more than x11-common. something is starting and putting a socket in there for the test to fail
[14:09] <ogra_> having an active socket in there is not okk though
[14:09] <sergiusens> ogra_, to be fair qtgui4 also deps on ice6
[14:09] <ogra_> and that socket i'm still confident comes from xvfb
[14:13] <ogra_> hmm, no
[14:14] <ogra_> installing ofono-phonesim and xvfb doesnt get me any socket
[14:14] <ogra_> could it be that autopilot initializes something that creates it ?
[14:18] <ogra_> like making use of xinput and thus initilizing parts of X ?
[14:18] <ogra_> (wildly guessing here indeed)
[14:20] <jdstrand> maybe doing 'lsof | grep /tmp/.X11-unix/X0' would lead to a clue
[14:20] <jdstrand> err
[14:20] <jdstrand> lsof | grep /tmp/.X11-unix/X99
[14:20] <rsalveti> morning
[14:20] <jdstrand> of course, I had psivaa remove the file, so would have to restart the test
[14:21] <jdstrand> hey rsalveti :)
[14:21] <sil2100> popey: hmmm, does the terminal app work for you on the latest image?
[14:22] <psivaa> jdstrand: so, after removing the file, restarting the device creates again. and the tests failing
[14:22] <didrocks> davmor2: popey: no lockup for you yet?
[14:22] <davmor2> didrocks: nope
[14:22] <ogra_> psivaa, so do an lsof
[14:22] <ogra_> or fuser
[14:23] <popey> hmm, i have a very long running init process on mine
[14:23] <didrocks> kgunn: agreed to keep the unity-mir issue "under the radar" for now
[14:23] <ogra_> to find what process owns it
[14:23] <popey> sil2100: latest = 246?
[14:23] <kgunn> didrocks: not "under the radar"...more like we're running the radar, and if we see it, we'll jump on it
[14:23] <kgunn> just not running radar for it per se :)
[14:24] <didrocks> kgunn: yeah, we agree :)
[14:24] <davmor2> sil2100: have you done a fresh install?
[14:24] <popey>    1943 phablet   20   0   30076  25960   1204 R  71.8  1.4 152:19.92 init
[14:24] <popey>  2637 phablet   20   0  107196  15388   7076 R  56.4  0.8 103:14.92 unity-scop+
[14:24] <popey> a bit unwell is my phone
[14:24] <sil2100> popey: yes, 246
[14:24] <popey> -rw-r----- 1 phablet phablet 1008M Mar 19 14:24 dbus.log
[14:24] <popey> oof
[14:24] <ogra_> neat
[14:25] <davmor2> man nearly a GB of log
[14:25] <popey> http://paste.ubuntu.com/7120047/
[14:25] <popey> lots of that
[14:25] <psivaa> ogra_: jdstrand: http://pastebin.ubuntu.com/7120043/
[14:25] <psivaa> lsof
[14:25] <ogra_> heh
[14:25] <ogra_> so it is xvfb
[14:26] <ogra_> seems installing it is not enough ... something needs to run it :)
[14:26] <ogra_> popey, now the question is why the heck do we run deed
[14:26] <ogra_> *dee
[14:27] <jdstrand> we should see who the parent of pid 2121 is
[14:29] <ogra_> popey, http://people.canonical.com/~ogra/touch-image-stats/241.changes ... it changed in 241 apparently
[14:29] <psivaa> jdstrand: http://pastebin.ubuntu.com/7120071/
[14:30] <ogra_> that cant be
[14:30] <ogra_> oh
[14:30] <ogra_> it can ... since your tests are run via adbd
[14:30] <psivaa> ogra_: yes
[14:31] <ogra_> so what is 2678 ?
[14:31] <psivaa> but why from image 245? :)
[14:31] <psivaa> ogra_: http://pastebin.ubuntu.com/7120080/ probably the command itself
[14:31] <jdstrand> doesn't --ppid=2138 not give us what we want?
[14:32] <jdstrand> that should list the shildren of 2138, no?
[14:32] <jdstrand> children
[14:32] <ogra_> psivaa, ah, right
[14:32] <jdstrand> but Xvfb is 2138
[14:33] <ogra_> well, again, we need to get rid of having xvfb installed at all ... except for tests that actually need it
[14:33] <psivaa> this is rdepends of Xvfb if it helps: http://pastebin.ubuntu.com/7120085/
[14:33] <ogra_> right
[14:33] <ogra_> ofono-phonesim-autostart
[14:33] <Saviq> retoaded_afk, hey, we're having weird failures in otto: https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/3548/console
[14:33] <ogra_> that should only be there when dialer or messaging tests are run
[14:34] <Saviq> retoaded_afk, looking at the history it happened this morning and is broken since:
[14:34] <Saviq> https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/
[14:34] <Saviq> tsdgeos, ↑
[14:34] <popey> bah, rebooted phone.. now unity wont start
[14:34] <ogra_> popey, out of diskspace ?
[14:34] <popey> maybe
[14:34]  * popey stabs dbus.log in the face
[14:35] <popey> with flowers
[14:35] <popey> \o/
[14:35] <ogra_> trying to kill it with hayfever ?
[14:35] <seb128> didrocks, sil2100, Mirv: is that a known issue? http://162.213.34.102/job/landing-018-1-build/6/console
[14:35] <psivaa> ogra_: ok, it looks like ofono-phonesim-autostart is getting installed during click-package setup
[14:35] <seb128> "UnboundLocalError: local variable 'cmd' referenced before assignment"
[14:36] <ogra_> psivaa, can we move it to the respecting test deps instead ?
[14:36] <ogra_> *respective
[14:36] <ogra_> for dialer and messaging
[14:36] <popey> sil2100: so, in answer to your question, yes, terminal starts fine here.
[14:36] <didrocks> seb128: hum, no and nothing changed recently
[14:36] <didrocks> seb128: let me look
[14:36] <seb128> didrocks, thanks
[14:36] <ogra_> (and have some command that removes it after the tests are run)
[14:37] <retoaded> Saviq, checking
[14:38] <didrocks> seb128: ahah, you have a MP withot commit message but with a debian/changelog content I guess!
[14:38] <seb128> didrocks, I should not have any debian/changelog there... let me check
[14:39] <seb128> didrocks, oh, you are right
[14:39] <seb128> the one from the oem team
[14:39] <seb128> https://code.launchpad.net/~binli/unity-control-center/1291862/+merge/211258
[14:39] <didrocks> \o/
[14:39] <didrocks> seb128: let me fix that :p
[14:39] <seb128> didrocks, thanks
[14:39] <didrocks> I wonder why pyflake didn't yell though
[14:39] <seb128> didrocks, should I set a commit message?
[14:39] <didrocks> seb128: no, it fallbacks to debcommit in that case
[14:39] <didrocks> seb128: seems you are the first one to test it though :p
[14:40] <davmor2> sil2100: did you resolve the terminal app issue?  it looks like the 0 size font issue is still there on  a fresh install
[14:40] <seb128> didrocks, ;-)
[14:40] <seb128> didrocks, well, is it going to take only that 1 changelog entry or append the commit messages from the other ones?
[14:40] <didrocks> seb128: fix deployed, please retry
[14:40] <didrocks> seb128: it will run "debcommit"
[14:41] <didrocks> so that's from that merge
[14:41] <didrocks> nothing else is generated beforehand
[14:41] <didrocks> what's*
[14:41] <seb128> didrocks, retried
[14:42] <sil2100> davmor2, popey: it didn't want to start here, but I do have some modifications from earlier
[14:42] <doanac`> didrocks, asac, cjohnston: FYI: the ci dashboard should be back to normal now after the system-image changes.
[14:43] <cjohnston> thanks doanac`
[14:43] <doanac`> no more stuff showing up under the "ubuntu" release
[14:43] <davmor2> sil2100: once I adjust the font size from setting it is fine :)
[14:43] <didrocks> doanac`: excellent, thanks!
[14:43] <doanac`> cjohnston was really the one who noticed what was going on. i just did the grunt work
[14:44] <didrocks> seb128: passed :)
[14:46] <seb128> didrocks, thanks!
[14:46] <didrocks> yw, sorry for the issue :)
[14:54] <bfiller> sil2100: can we get a silo for line 52 please to fix a browser/qt5.2 related bug?
[14:54] <sil2100> bfiller: sure, let me look
[14:56] <davmor2> kgunn: I just gave your manual test coverage a quick once over I don't see device rotation there or is that automated?
[14:56] <sil2100> bfiller: assigned!
[14:56] <davmor2> kgunn: other than that looks good :)
[14:57] <bfiller> sil2100: thanks
[14:57] <Laney> Mirv: may I publish qtbase?
[14:59]  * didrocks goes for a run
[15:00] <retoaded> Saviq, is the job supposed to be generating a new container for each run or reusing an existing container?
[15:00] <Laney> Mirv: also, could you commit that to Debian please?
[15:01] <Saviq> retoaded, I believe a clean one for each run
[15:02] <kgunn> davmor2: inspired...i added another scenario i do all the time which covers rotation
[15:02] <kgunn> and copy/paste
[15:03] <davmor2> kgunn: cool
[15:03] <retoaded> Saviq, that might explain it then; it looks like it is reusing a container from 20140314
[15:04] <Saviq> retoaded, well, it might use it, but clean it afterwards?
[15:04] <Saviq> retoaded, fginther knows details
[15:04] <Saviq> retoaded, it only broke today, and the failure suggests some script got renamed / removed
[15:09] <retoaded> Saviq, yes, the stop_running_container script was missing; have put a copy back in place.
[15:10] <retoaded> Saviq, perhaps the fact the container was not being stopped is causing the issue. Will see after this run.
[15:11] <Saviq> retoaded, thanks
[15:20] <davmor2> popey: can you try the following please https://bugs.launchpad.net/address-book-service/+bug/1294710
[15:20] <popey> davmor2: on a call.. will in a bit
[15:23] <davmor2> popey: ta
[15:25] <dbarth_> sil2100: i have a build stuck on powerpc for ages: can i get rid of that with a debian/control change?
[15:25] <dbarth_> http://162.213.34.102/job/landing-006-1-build/94/console
[15:26] <sil2100> dbarth_: no no, you have to wait for the builds to happen now
[15:26] <sil2100> dbarth_: all architectures are now buildable, so the only thing we can do is wait now sadly
[15:26] <sil2100> dbarth_: the build should start soon I guess
[15:26] <dbarth_> ok
[15:27] <sil2100> dbarth_: you can do testing in the meantime :)
[15:28] <dbarth_> oh, the ppa is ready?
[15:28] <dbarth_> checking
[15:37] <cjwatson> dbarth_: it's building on our fastest builder now, anyway
[15:38] <cjwatson> (actually maybe it isn't the fastest now that we have those ppc64el beasts, not sure)
[15:38] <psivaa> doanac`: will there be any fallouts if we run the smoke without packages='ALL' ? looks like each app test installs the deps from testconfig.py anyway
[15:38] <sil2100> dbarth_: I saw all other archs finished, just powerpc was still pending
[15:39] <doanac`> psivaa: "packages" is no longer a config option for the job. i killed it yesterday
[15:39] <doanac`> for that very reason
[15:39] <dbarth_> ok
[15:39] <psivaa> doanac`: ohh ok, does it mean that we need to regenerate the jobs?
[15:40] <doanac`> psivaa: i believe i did regenerate
[15:40] <psivaa> doanac`: http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-daily/configure  does have the PACKAGES option?
[15:42] <doanac`> psivaa: hmm. let me re-sync in a bit. i'm in a meeting right now.
[15:42] <rsalveti> ogra_: http://ci.ubuntu.com/smokeng/trusty/touch/mako/246:20140319.2:20140304/7259/shorts_app/ mpdecision is probably up here because unity8 is consuming 113%
[15:42] <psivaa> doanac`: ack,
[15:43] <rsalveti> http://ci.ubuntu.com/smokeng/trusty/touch/mako/246:20140319.2:20140304/7259/ubuntu_filemanager_app/ here is udev, which is weird
[15:43] <ogra_> hmm, i didnt see unity8
[15:45] <ogra_> rsalveti, thats only in the first few samples though, it settled then
[15:45] <Laney> Mirv: timeout; I'm going to publish
[15:46] <rsalveti> ogra_: right, but it might be the cause
[15:56] <retoaded> Saviq, the build failed but the stop_running_container script ran which should give a clean container for the next run.
[15:56] <Saviq> retoaded, great, thanks!
[16:03] <psivaa> ogra_: so doanac` has in fact made the necessary changes to install the packages only when required, this will fix the security test failures. job regeneration is left now
[16:04] <ogra_> yay
[16:04] <ogra_> thanks !
[16:08] <psivaa> to doanac` ^ :)
[16:09] <mhr3> sil2100, silo for #53 pls?
[16:10] <jdstrand> apparmor-easyprof-ubuntu tests are less brittle now too
[16:10] <jdstrand> click-apparmor is being work on (adding an extra test)
[16:11] <sil2100> mhr3: looking! Although we're still low on silos ;)
[16:12] <sil2100> mhr3: there are some that I published, just still waiting for them to migrate
[16:13] <sil2100> sergiusens: can you m&c landing-014? Thanks!
[16:13] <mhr3> sil2100, oh come on, two are free :P
[16:14] <sil2100> mhr3: ;p
[16:14] <sil2100> mhr3: we have to have at least 3 free silos ;)! That's our internal rule
[16:14] <mhr3> sil2100, plus the sooner you give it to me, the sooner i give it back :)
[16:15] <mhr3> sil2100, or give me 005 for #53
[16:15] <mhr3> sil2100, it won't move until tomorrow
[16:16] <sil2100> sergiusens: ok, I'll do the m&c in the meantime, since I'm longing for some silos right now
[16:16] <sil2100> mhr3: wait a moment
[16:18] <sil2100> mhr3: I'm freeing up one silo anyway right now, I'll have something to assign in a few minute
[16:18] <mhr3> sil2100, ok, ty
[16:36] <didrocks> bfiller: if you are not available to the landing team meeting, can you please refresh us on bug #1293610 (either now or per email)?
[16:36] <didrocks> bfiller: I just noted for the email right now:  -> put under that category as we didn't get it in past 5 images. However, Leo has a pending fix to make the test more reliable.
[16:36] <didrocks> (that category == non blocking because didn't get for a long time)
[16:36] <sil2100> mhr3: ok, had to free 005 anyway since -mediascanner scope was allocated there as well
[16:38] <mhr3> sil2100, right
[16:40] <davmor2> didrocks: so I've been using 246 on mako/flo/manta it is far more stable \o/  still found a couple of issues obviously though :)
[16:40] <ogra_> stop finding issues !
[16:40] <ogra_> :)
[16:40] <davmor2> ogra_: it's my job
[16:41] <davmor2> ogra_: these shouldn't on the whole stop promotion though they are mostly app issues that have possibly been around for a while and just noticed today in exploratory testing :)
[16:42] <ogra_> whee
[16:42] <davmor2> ogra_: except for the unity8 crasher when searching if you have music on the device from this morning :)
[16:42]  * ogra_ doesnt have music from this morning on his device
[16:42] <ogra_> :P
[16:43] <bfiller> didrocks: yes there is a pending MR for the fix for that
[16:43]  * davmor2 passes ogra_ some music from this morning they are a great group you should listen to them more regularly :P
[16:44] <ogra_> lol
[16:46] <didrocks> bfiller: ok, so will probably land today?
[16:46] <didrocks> davmor2: no lock?
[16:46] <bfiller> didrocks: yes it will
[16:46] <davmor2> didrocks: nope not on any of the devices
[16:46] <didrocks> thanks bfiller
[16:46] <bfiller> boiko: please prepare the landing for the test fix if you haven't already
[16:51] <boiko> bfiller: I was waiting for elopio to be around to give it a try
[16:57] <elopio> boiko: I'm here.
[16:57] <davmor2> didrocks: https://bugs.launchpad.net/bugs/1294710 and https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1294605 and there are the old favourites like bt headset, wired audio etc all being a bit naff :)
[16:58] <elopio> let me compile the app and install it on the phone.
[16:58] <didrocks> davmor2: ok
[16:58] <elopio> boiko: how are you doing that? Just sudo make install on the phone?
[16:59] <boiko> elopio: well, I applied the diff manually on the device for the first tests, and then for the final round of testing I build the armhf package, let me see if I still have it around (I have switched over to test something else, might have lost it)
[17:01] <didrocks> popey: coming?
[17:02] <didrocks> robru: coming?
[17:02] <popey> didrocks: yeah, 1 sec, kids just came home
[17:02] <didrocks> kgunn: coming?
[17:02] <elopio> didrocks: do I have to attend that meeting? I noticed I was invited, I'm not sure what is it about or how should I participate.
[17:02] <boiko> elopio: nope, the packages are gone :/
[17:02] <nuclearbob> cking: are you still around?
[17:03] <didrocks> elopio: do you have anything to update on some blocking issues?
[17:03] <cking> nuclearbob, indeed I am
[17:03] <elopio> didrocks: I'm focusing on test plans this week, so no.
[17:03] <didrocks> elopio: ok
[17:04] <nuclearbob> cking: the new job I'm testing doesn't use utah to do the reboot, it just does a reboot and then sleeps for a while to let bootchart do its thing uninterrupted.  That's making the job run a lot longer, so it may be a while before I have results.  Is there a quick way I can evaluate whether it's addressing the problem other than just checking the final timings, or is that the best way?
[17:05] <cking> nuclearbob, i'm not sure, I'm not really the owner of the test, I just noticed it wasn't working as expected
[17:05] <jdstrand> fyi, bug #1294667 fixed for security tests. I guess it was also fixed another way too
[17:05] <nuclearbob> cking: okay.  How did you identify that utah-done was likely a cause of the issues?  Looking at the bootchart, or something else?
[17:06] <cking> nuclearbob, I just observed it was in the bootchart, and there were excessive waits caused by it
[17:06] <cking> just used my very basic boot chart eyeballing techniques
[17:06] <nuclearbob> cking: okay, cool.  It shouldn't be in there in the new results at all, so I'll check for that when the job is done, and let you know how things are going
[17:06] <cking> that's great, thanks!
[17:09] <boiko> bfiller: MR is in the spreadsheet, now let's just wait for silo assignment
[17:10] <popey> davmor2: can you add a fb account in online accounts on ubuntu phone?
[17:10] <popey> davmor2: i get a dump of html after clicking "Save browser" when signing into facebook
[17:10] <popey> http://popey.com/~alan/phablet/device-2014-03-19-170951.png
[17:12] <davmor2> popey: no it worked for me
[17:12] <popey> just done it twice
[17:13] <balloons> plars, didrocks what still fails with sudoku, have a trace?
[17:14] <didrocks> balloons: http://ci.ubuntu.com/smokeng/trusty/touch/mako/245:20140318.2:20140304/7250/sudoku_app/919515/
[17:14] <balloons> ty
[17:17]  * popey reboots
[17:19] <popey> davmor2: nope, happens every time
[17:20]  * popey files a bug
[17:20] <davmor2> popey: I wonder if it is an issue on fb let me try with another device I setup my account about 30 minute + ago
[17:20] <popey> do you have your fb account setup to popup when you login from a new machine?
[17:20] <popey> (I do)
[17:21] <popey> http://popey.com/~alan/phablet/device-2014-03-19-171227.png that dialog
[17:21] <davmor2> popey: no idea
[17:21] <popey> no then
[17:21] <popey> do you see that when you sign in?
[17:23] <davmor2> popey: no but I do have login approvals on
[17:25] <davmor2> popey: just logged in no issues
[17:26] <popey> right, can you enable the setting?
[17:26] <davmor2> popey: sure if I can find it
[17:27] <popey> Settings -> Login notifications
[17:30] <davmor2> popey: so according to facebook security it's all enabled but I don't see that page anywhere
[17:30] <popey> bug 1294768
[17:33] <popey> davmor2: also, without signing into twitter, do you get this on the online accounts-twitter thing? alan/phablet/device-2014-03-19-173249.png
[17:35] <davmor2> popey: if I goto accounts and click on twitter I get that yes that is apparently the default twitter sign in page for mobile
[17:35] <davmor2> popey: it's the same page I get on my s3 under android
[17:35] <popey> niiiiice
[17:35] <davmor2> popey: I think the page size is fixed
[17:36] <davmor2> ish
[17:36]  * popey files a bug anyway
[17:37] <davmor2> popey: as for face book I have notification enabled I get them via email however I have logged in with all of these devices before so I don't get the warning now
[17:37] <popey> try when you next clean flash ☻
[17:38] <popey> (please)
[17:38] <davmor2> will do
[17:40] <popey> ta
[18:05] <Laney> just freeing silo 001 now, sorry for delay
[18:15] <robru> Laney, thanks, no worries
[18:32] <dbarth_> robru: hi, i need a nudge on silo 6 in which i had to remove a component
[18:33] <dbarth_> (was blocking kenvandine for his content-hub updates)
[18:33] <kenvandine> dbarth_, woot :)
[18:34] <robru> dbarth_, reconfig?
[18:35] <robru> dbarth_, deleted unity-webapps-qml from the ppa for you
[18:36] <robru> dbarth_, takes a few minutes to process though
[18:38] <robru> dbarth_, ok, here's a watch_only build to fix the silo status: http://162.213.34.102/job/landing-006-1-build/97/console should work
[18:41] <sergiusens> robru, can I get a silo for l57/u-d-m ?
[18:42] <robru> sergiusens, ok, you got silo 1
[18:42] <sergiusens> ty
[18:42] <dbarth_> robru: thanks
[18:43] <robru> Saviq, what's the status of silo 7?
[18:43] <robru> dbarth_, you're welcome
[18:43] <robru> sergiusens, also welcome
[19:04] <thomi> doanac: got a second?
[19:04] <thomi> I'm seeing a traceback in the combine_results script: http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/83/label=mako-07/console
[19:04] <thomi> at the very bottom of that page ^^
[19:04] <thomi> 'return results[0].attrib.get('classname', '???').split('.')[0]'
[19:05] <thomi> which obviously won't work - if you get the default value from 'get()', your '.split()[0]' will fail!
[19:10] <thomi> robru: cyphermox: I don't seem to be able to open the self-service spreadsheet I get a 502 error. Are you seeing the same?
[19:11] <robru> thomi, checking
[19:12] <robru> thomi, I'm not getting a 502 but it's not loading
[19:12] <thomi> :(
[19:12] <robru> thomi, oh, nope, it just loaded _really_ slowly
[19:12] <thomi> my autopilot release is finally tested, and I can't update the spreadsheet... that's like... running  a marathon but not being able to find the finish line!
[19:13]  * thomi spams the reload button
[19:13] <robru> thomi, it's ok, because jenkins is still accessible for publishing, but it's even more  ok than that because I'm not going to publish it right now anyway ;-)
[19:13] <thomi> woooo!
[19:14] <thomi> We got *zero* failures on our test run, which, last I looked was better than the dashboard results
[19:14] <robru> thomi, waiting for a couple critical fixes to land, then kick an image, then hopefully promote an image, then we can break everything with a big autopilot landing ;-)
[19:14] <thomi> I think the new upstart app launch support will make things more stable
[19:14] <robru> hmmm, spreadsheet is quite unresponsive.
[19:15] <thomi> robru: it works for me now too
[19:15] <thomi> probably the NSA splicing some wires somewhere...
[19:15] <robru> totally
[19:16] <thomi> well, now I can prepare for the next autopilot landing :)
[19:16] <robru> thomi, yeah it might be a while. I haven't heard anything from any of my high-priority landings...
[19:17] <boiko> robru: landing-009 tests passed, ready to land
[19:17] <robru> boiko, is this one filled exclusively with important bugfixes and no regressions?
[19:17] <boiko> robru: nope, new features there
[19:17] <robru> boiko, ok, that'll have to wait for the next image then.
[19:18] <boiko> robru: for bugfixing I need a silo for line 54 :D
[19:18] <robru> boiko, that I can do
[19:18] <boiko> robru: great! thanks!
[19:19] <robru> boiko, ugh, except it conflicts with silo 9 :-/
[19:19] <robru> boiko, how critical are those bugfixes? I can force-assign a silo for it, but then it will invalidate the testing you did in silo 9 (eg you will have to rebuild & retest messaging-app in silo 9 later)
[19:19] <tvoss> sil2100, ping
[19:20] <robru> tvoss, i doubt sil2100 is still around, can I help?
[19:23] <boiko> robru: well, there was this one autopilot test that failed last friday and elopio tried a workaround which didn't work. but now the test is passing by pure luck, so I wrote a definitive fix for it
[19:23] <boiko> robru: but it is only fixing the test, not fixing the app itself
[19:24] <boiko> robru: so I would say it is not critical
[19:24] <robru> boiko, is this failure one of the ones that didrocks is considering as blocking image promotion?
[19:25] <boiko> robru: yes, it is
[19:25] <robru> crap
[19:25] <elopio> boiko, robru: it's on the section: " ** Non blocking new issues since last promoted image (doesn't impact user experience or really rare bug) **"
[19:26] <robru> elopio, oh ok great
[19:26] <robru> that answers that
[19:26] <robru> boiko, so we'll just wait on that landing. after the next image gets kicked we can publish silo 9 then assign a new silo for this
[19:27] <robru> bfiller, Saviq: any word on those critical fixes I'm waiting for? can i help test anything?
[19:27] <dbarth_> robru: silo 6 is good to go (testing done)
[19:27] <robru> dbarth_, thanks
[19:27] <dbarth_> you can publish and land / merge later today
[19:27] <robru> dbarth_, whats the story with silo 6? are those fixes critical? how likely is a regression?
[19:27] <boiko> elopio: where is that from? I looked at the email didrocks sent yesterday and there it is under the blocking issues
[19:28] <dbarth_> html5 sdk bug fixes; so nothing critical
[19:28] <elopio> boiko: he sent it two hours ago
[19:28] <boiko> elopio: ah ok
[19:28] <elopio> Landing team meeting 19.03.14
[19:28] <dbarth_> i've tested with the sample apps and tutorial apps on phone & desktop
[19:28] <robru> dbarth_, ok i can do that later on today then
[19:28] <dbarth_> cool
[19:28] <boiko> elopio: yep, just saw that
[19:29] <boiko> robru: so, it is fine, I can wait until the next image gets kicked
[19:30] <robru> boiko, ok. I don't have an estimate on the timeline, it might be several hours...
[19:31] <boiko> robru: ouch, really?
[19:31] <robru> popey, kgunn any word on those fixes?
[19:31] <popey> which fixes?
[19:31] <robru> popey, the calendar-app ones
[19:31]  * popey points robru at balloons 
[19:31] <robru> boiko, yeah, I was told to highly prioritise a couple fixes this morning, and I haven't heard anything about their status so far yet today.
[19:31] <robru> balloons, any word on that calendar-app fix?
[19:32] <balloons> I accepted chris's suggested fix, but it doesn't merge due to https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1294181
[19:33] <robru> balloons, uhhh, so... can I expect that to land in the next 6 hours?
[19:33] <boiko> robru: that's not good, but anyway, if there is nothing you can do I will just wait
[19:33] <robru> balloons, or is it blocked?
[19:33] <balloons> not quite..
[19:34] <balloons> all landing for calendar is blocked on that
[19:34] <robru> boiko, yeah, we are really close to an image promotion, don't want to risk it with any non-critical fixes
[19:34] <robru> balloons, what needs to be done to fix it? i don't really understand the bug. I've got some time to help if there's anything I can do
[19:34] <boiko> robru: ok
[19:34] <kgunn> robru: dont know much about calendar app...i was keeping an eye on line 50
[19:35] <kgunn> but it seems it says error! in the cell concerning silo/build state
[19:35] <robru> kgunn, sorry I pinged you about unity8/mir fixes. silo 7
[19:35] <balloons> robru, at this point chasing down omer's suggestion might be a good one. What is known is that it only affects weather, the toolkit helpers seem fine, and my guess it it's something in the qml implementation
[19:35] <balloons> *calendar, not weather hah
[19:35] <robru> kgunn, yeah the spreadsheet is a bit sloppy. looking at the backend the status is built, so please test the silo
[19:38] <robru> kgunn, are you blocked or can you move forward?
[19:41] <kenvandine> bfiller, is gallery-app the last of the packages blocking getting the content-hub silo?
[19:42] <bfiller> kenvandine: havne't checked as still working on gallery to get that unblocked. that should happen today
[19:42] <kenvandine> ok, great
[19:42] <kenvandine> i think that's the only one left
[19:43] <kenvandine> bfiller, have you figured out why CI isn't running for the peer_picker_ui branch?
[19:44] <bfiller> kenvandine: I was told because it's marked as depends on another branch
[19:46] <robru> ok, I gotta break for lunch.
[19:46] <kenvandine> bfiller, all but one of my branches have a prereq
[19:46] <kenvandine> and they all ran CI
[19:48] <bfiller> kenvandine: I don't know then, sergiusens who can help get CI to run on this branch? https://code.launchpad.net/~michael-sheldon/content-hub/peer_picker_ui/+merge/211092
[19:48] <bfiller> does michael-sheldon need ot be added to whitelist somehwere?
[19:48] <bfiller> fginther: ^^^^
[19:49] <sergiusens> bfiller, yeah, I asked cjohnston iirc, but fginther knows where this is
[19:49] <cjohnston> bfiller: he's included
[19:49] <sergiusens> bfiller, he said the prereq needed to merge first; but if that's the case; it's new
[19:49] <cjohnston> sergiusens: aiui its been that way forever
[19:50] <bfiller> cjohnston: not according to kenvandine, ken do you have examples of MR's that have prereq's that run through CI?
[19:50] <sergiusens> cjohnston, no it hasn't; I was there when this was implemented with mmrazik
[19:50] <kenvandine> https://code.launchpad.net/~ken-vandine/content-hub/peer_details/+merge/210008
[19:50] <cjohnston> Don't know then. All I know is what I was told by fginther
[19:53] <sergiusens> bfiller, cjohnston if jenkins-launchpad-plugin is still being used, you need to add the user in allowed_users http://bazaar.launchpad.net/~private-ps-quality-team/jenkins-launchpad-plugin/trunk/view/head:/jlp.config
[19:53] <sergiusens> on the server
[19:53] <cjohnston> sergiusens: fginther said that every time the main job runs, the whitelist is updated
[19:53] <sergiusens> bfiller, the other option you have is to manually trigger the job from jenkins
[19:57] <bfiller> cjohnston: can you please get this resolved ASAP and at least manaully trigger this job?
[19:57] <sergiusens> bfiller, I triggered it manually
[19:58] <bfiller> sergiusens: thanks
[19:58] <cjohnston> bfiller: I'd suggest an email to the CI team ML as fginther is quite busy this week
[20:07] <bfiller> robru: getting this error on reconfiguration, can you help? http://162.213.34.102/job/landing-015-0-reconfigure/4/console
[20:07] <Saviq> robru, it's ready to test, I just wanted to do another quick round of testing after an added commit
[20:07] <bfiller> robru: I added thumbnailer and it wasn't in there before
[20:11] <seb128> yeah, #errors# went away, workling list is back
[20:11] <seb128> working
[20:14] <robru> bfiller, yeah, in that case when you want to add a component you need us to reconfig it. the reconfig option for you is only for changing MPs when the projects stay the same
[20:14] <robru> bfiller, on it
[20:14] <bfiller> robru: thanks
[20:14] <sergiusens> bfiller, cjohnston fginther "DEBUG: User "michael-sheldon" not allowed to trigger jobs"
[20:14] <sergiusens> http://s-jenkins.ubuntu-ci:8080/view/click/job/trigger-ci-on-stacks/14646/consoleFull
[20:14] <sergiusens> there you go
[20:15] <robru> bfiller, you're welcome. please rebuild.
[20:28] <fginther> bfiller, sergiusens, cjohnston, I've updated the whitelist for michael-sheldon
[20:29] <bfiller> fginther: thank you
[20:49] <bfiller> robru: silo-008 ready to be published
[20:50] <robru> bfiller, with critical fixes only? ;-)
[20:51] <bfiller> robru: well, it's a qt5.2 crasher
[20:51] <bfiller> but not on anyone's radar (yet anyway)
[20:51] <robru> bfiller, excellent, I can justify publishing that ;-)
[20:53] <Saviq> robru, kgunn, +1 on silo 7
[20:53] <robru> Saviq, thank you!
[20:53] <kgunn> cool
[21:05] <doanac> thomi: sorry. was at an appointment. can you open a bug for that please?
[21:05] <thomi> doanac:  sure - against what project?
[21:05] <doanac> ubuntu-ci-services should work
[21:06] <thomi> ok
[21:10] <thomi> doanac: not sure I got it on the correct project, but you can always reassign as you see fit: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1294859
[21:10] <doanac> thomi: that works. thanks!
[21:10] <thomi> nw
[21:10] <doanac> i'll try and fix that this evening
[21:31] <cjwatson> do we have any chance of getting line 18 (upstart-app-launch -> libclick) landed at any point?  I guess it collides with thomi's autopilot bits in silo 3; clipping 1.4 seconds off every click app startup would be *really* nice though
[21:32] <thomi> :(
[21:33] <thomi> what's the test plan for that cjwatson?
[21:34] <cjwatson> https://wiki.ubuntu.com/Process/Merges/TestPlan/upstart-app-launch should be fine
[21:35] <thomi> so, the test plan for autopilot takes ~ 4 hours to run. I realise there's more to it than this, but if we're going to invalidate one or the other silos, I'd rather it was the one with the smaller test plan
[21:35] <cjwatson> 'k, well, mine isn't in a silo yet
[21:36] <cjwatson> if you're actually genuinely close to landing yours, fine - I just didn't want mine to be open-ended
[21:36] <thomi> cjwatson: mine's ready now
[21:36] <cjwatson> because, you know, would be nice for the weeks of work on libclick to actually start paying off in terms of performance
[21:36] <thomi> just waiting for the landing team to ... do whatever it is they do to land stuff.
[21:36] <thomi> cjwatson: I know how you feel
[21:37] <thomi> robru: you mentioned you wanted a new image before landing the AP silo. Any idea when that'll happen?
[21:37] <cjwatson> I think I misunderstood robru's comment above about promoting an image before an ap release, or maybe not
[21:37] <cjwatson> if we want to promote an image first, then that's still kind of open-ended
[21:37] <robru> thomi, tough to say. one of the things I wanted in this image isn't coming, so I have to make a hard decision now. however unity8 is already in proposed so I guess I'll just kick an image after that and then open the door for landings.
[21:38] <thomi> I'll be dissapointed if they want to promote an image first, I figured they just wanted to spin a new one up
[21:38] <thomi> right
[21:38] <thomi> robru: so, just to be clear, you're not saying that a new image has to be promoted first, just a new image run done?
[21:39] <robru> thomi, cjwatson: well the word from didrocks this morning was that we only had 2 blockers to promote, and both fixes were supposed to be forthcoming, but so far I only got one and the other is blocked, so I'm not sure now: should I block everything on this, or should I move ahead with risky landings and perhaps make us farther away from a promotable image
[21:39] <robru> thomi, yeah, I think that's the decision I'm making right now
[21:39] <cjwatson> robru: mm, above my pay grade :)
[21:39] <robru> cjwatson, yeah me too
[21:40] <cjwatson> that's bug 1293489 and bug 1293478?
[21:40] <thomi> robru: so, my AP test run, which is identical to the smoke test run got 0 failures
[21:40] <robru> cjwatson, yep, from didier's landing email
[21:40] <thomi> So I guess I was lucky
[21:40] <cjwatson> haha, oh dear, I'm glad I looked, my hack for the indicator-network -> unity8 dep is confusing proposed-migration
[21:40] <robru> thomi, ok I'm glad to hear that. I'll publish it after the next image kick, which will probably be within 2 hours (depends on unity8 getting through proposed + image kick takes 1hr itself)
[21:41] <cjwatson> let me unconfuse that or it'll never get there
[21:41] <thomi> robru: thanks - let me know if you need anything from our end
[21:41] <robru> thomi, should be good but i'll ping you if i need anything thanks
[21:42] <cjwatson> there we go, fixed.  it didn't actually delay anything since there was a unity-scope-click autopkgtest to run anyway
[21:43] <robru> cjwatson, yeah, I'm just waiting on that
[21:43] <cjwatson> update_excuses is a bit hard to read right now with the giant pile of KDE stuff
[21:43] <robru> ogra_, cyphermox, rsalveti: is anybody around to kick an image build in an hour or so? once unity8 lands in archive
[21:44] <rsalveti> robru: sure
[21:44] <robru> rsalveti, great, I'm watching it, will ping you when it's time
[21:44] <robru> thanks
[21:44] <rsalveti> great
[22:13] <robru> rsalveti, ok, please kick an image build
[22:14] <rsalveti> robru: alright
[22:15] <robru> rsalveti, thanks
[22:18] <rsalveti> bot should announce it in a few minutes
[22:19] <rsalveti> bot is actually off :-(
[22:19] <rsalveti> ogra_: ^
[22:20] <rsalveti> [22:24] <robru> rsalveti, ah, thanks.
[22:26] <robru> thomi, hmmmm, actually I just saw didier's note in the spreadsheet, (even marked in red) he is really insistent on not publishing your silo until after we get a promoted image. sorry for the confusion, it's out of my hands
[22:26] <thomi> robru: so, we have another landing for AP getting queued up, Any idea how long this will delay us?
[22:27] <robru> thomi, at least a day.
[22:27] <thomi> well... that sucks :(
[22:27] <robru> thomi, yeah I'm sorry. I thought I was going to just be extra-careful testing today's landings, but your specifically is singled out for waiting
[22:28] <thomi> robru: ahh well, I guess I should have expected that.
[22:28] <robru> thomi, yeah, we are only one blocker away from a promotable image, too close to risk anything
[22:28] <thomi> I realise it's not your fault. It's extremely demotivating to always get landing delays, that's all
[22:28] <robru> thomi, yeah, i understand, sorry
[22:29] <thomi> no worries. veebers - that will delay the release you're working on ^^
[22:29] <veebers> thomi: aye, well at least we'll have the MRs ready and raring to go
[22:29] <thomi> veebers: I think the best option is to do all we can to make sure that release +1 is ready to go, but don't ask for a new silo.
[22:30] <veebers> aye, that's the plan.
[22:30] <thomi> veebers: hopefully we don't need to re-run the testing run after the new image
[22:30] <veebers> thomi: oh, good point :-\
[22:30] <veebers> I think I need another coffee
[22:31] <ogra_> rsalveti, eeek, sorry, forgot the reconnect
[22:34] <ogra_> (it will announce the 247 start again, ignore that
[22:34] <ogra_> )
[22:38] <imgbot> [22:38] <robru> yay!
[22:38] <ogra_> yeah, sorry, i need to add some watcher for the reconnect ...
[23:04] <rsalveti> ogra_: thanks!
[23:29] <imgbot> [23:29] <imgbot> [23:29] <robru> wahooooo!
[23:30] <robru> wow that's a bigger changelog than i thought
[23:33] <rsalveti> qtbase
[23:37] <robru> rsalveti, any idea if those qt changes can fix https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1294181
[23:38] <rsalveti> robru: no, latest qtbase changes were all packaging ones
[23:39] <robru> great
[23:50] <ToyKeeper> Hmm.  Video thumbnails aren't working in r247.
[23:51] <robru> ToyKeeper, seems fine to me. where's the problem?
[23:51] <ToyKeeper> This was fresh after flashing though; I don't think unity even had a chance to finish coming up before my script had the files copied.
[23:51] <robru> ToyKeeper, oh what kind of videos? local files?
[23:51] <ToyKeeper> Local files, the same ones as used in the MWC demo.
[23:52] <ToyKeeper> The icons were just a film strip with a > symbol.
[23:52] <rsalveti> yeah, just try to reboot to see
[23:52] <ToyKeeper> Already doing so.
[23:52] <robru> ToyKeeper, oh, thumbnailer's not in this image
[23:52] <ToyKeeper> Nope, didn't help.
[23:53] <ToyKeeper> Huh, it successfully received a test message during first boot, before Unity started.
[23:53] <ToyKeeper> s/test/text/
[23:53] <ToyKeeper> That was random.  Good to know the sounds still work even when Unity isn't running.
[23:54] <robru> ToyKeeper, are you able to enable silo 15 and check if it fixes the thumbnail bug? if so I'll publish that one. but I'm trying really hard to avoid regressing right now
[23:54] <ToyKeeper> Perhaps, but I've got to go in a few.  (back later)
[23:56] <robru> ToyKeeper, hmmm, actually i just copied a local file and i got a thumbnail for it. mp4 format. maybe the bug only exists for certain video format?
[23:57] <ToyKeeper> apt-add-repository ppa:ci-train-ppa-service/landing-015  ?
[23:57] <robru> ToyKeeper, looks right, then just dist-upgrade
[23:58] <ToyKeeper> It always takes forever to update the deb-src repos.  :(
[23:59] <robru> yep