[04:36] <ToyKeeper> So, this was cool: http://toykeeper.net/tmp/phablet/2014-08-04/wifi-settings-layout-broken.png
[04:40] <bzoltan> Guys, i am executing the UITK test plan right now.. pretty much doing the same test set as the CI dash.  I see that the CI dash shows scary amount of failures...
[04:47] <Mirv> Kaleo: jhodapp: line 27 for qtubuntu-camera (ensure directory exists) conflicts with silo-003 (audio recording), do you want to land the line 27 first or wait until 003 has been landed?
[04:56] <bzoltan> Mirv:  do you know what the hack is happening with the autopilot tests? The CI dash shows tons of failures.
[05:10] <ToyKeeper> bzoltan: I'm not sure, but I heard mumblings earlier today about being unable to make a new image until something in the process was fixed...  so image 171 didn't happen.  I haven't checked on the details though.  Perhaps related?
[05:17] <bzoltan> ToyKeeper: I do not know.. I just woke up and watched my own nightly tests for the ongoing UITK landing. Horror...
[05:42] <Mirv> some devices are apparently failing which cause havoc to the numbers
[05:42] <Mirv> or that was the general idea yesterday at least
[06:00] <Mirv> bzoltan: you were offline, but there is some problems with some of the devices. the 169 mako results for example were repeated for more times and show "truer" results: http://ci.ubuntu.com/smokeng/utopic/touch/mako/169:20140804:20140728.1/9466/
[06:25] <sergiusens> Mirv: hey, can you check silo 2 for me?
[06:30] <Mirv> sergiusens: I can't do the packaging ack unfortunately :(
[06:30] <Mirv> since I'm not coredev
[06:30] <sergiusens> Mirv: can rsalveti do the ack?
[06:30] <rsalveti> packaging ack is fine
[06:30] <sergiusens> Mirv: it's a preNew thing
[06:31] <Mirv> yes he can, it's a new package though
[06:31] <rsalveti> This source is a new package, if the destination is ubuntu, please ensure it has been preNEWed by an archive admin before publishing that stack.
[06:31] <rsalveti> right
[06:31] <rsalveti> that's the message
[06:31] <Mirv> prenew acks used to be only doable by https://launchpad.net/~ubuntu-archive/+members
[06:31] <rsalveti> yeah, not by me
[06:31] <Mirv> seb might be awake since he's in China tz
[06:31] <rsalveti> yeah, seb128_, able to help with that?
[06:32] <Mirv> ( = pre-new acking https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-002/+packages 's ciborium package)
[06:34] <seb128_> rsalveti, Mirv: in a meeting, which one?
[06:34] <seb128_> can look in a bit
[06:34] <rsalveti> seb128: ciborium, from silo 02
[06:35] <seb128> rsalveti, k
[06:36] <Mirv> rsalveti: while you're there, packaging pre-check for qtdeclarative-gles https://launchpadlibrarian.net/181499705/qtdeclarative-opensource-src-gles_5.3.0-0ubuntu3_5.3.0-0ubuntu4.diff.gz would be welcome, in case I get testing done at some point
[06:37] <Mirv> rsalveti: changelog for the respective qtdeclarative: http://pastebin.ubuntu.com/7958613/
[06:38] <rsalveti> Mirv: change looks fine, just need testing though
[06:38] <slangasek> sil2100: FYI, I didn't quite get autopilot-qt4 off the image yesterday; I'm building a new one now that autopilot 1.5.0+14.10.20140716-0ubuntu2 is in
[06:39] <Mirv> rsalveti: thanks. I'm battling my way through autopilots and manual testing.
[07:18] <bzoltan1> Mirv: about the UITK landing... I have run multiple times all the tests... the shorts, music, calendar and address book apps have same ugly test results with the release candidate UITK, all other tests are OK
[07:18] <bzoltan1> Mirv:  should we land the UITK?
[07:19] <jibel> network list in the indicator and system-settings is broken on #171
[07:20] <seb128> jibel, settings tests started failing as well, we think it might be the ofono landings
[07:20] <seb128> I pinged rsalveti about it
[07:20] <jibel> seb128, is there is bug # ?
[07:20] <ToyKeeper> jibel: I filed a bug for that for 170...
[07:20] <seb128> but not sure anyone is looking at it
[07:20] <jibel> ToyKeeper, ok
[07:20] <rsalveti> let me ping abeato
[07:20] <seb128> rsalveti, thanks
[07:20] <ToyKeeper> jibel: Bug 1352684.
[07:21] <Mirv> bzoltan1: music, calendar and address book have known failures, so please compare if you get the same individual test failures as shown at http://ci.ubuntu.com/smokeng/utopic/touch/mako/169:20140804:20140728.1/9466/ - shorts should pass, though
[07:22] <Mirv> although #171 does show a shorts failure too: http://ci.ubuntu.com/smokeng/utopic/touch/mako/171:20140805:20140728.1/9484/shorts_app/ is yours the same there too?
[07:22] <ogra_> ugh ... 13 of the 15 crashes in the 171 tests are indicator-network ... wow, that's bad
[07:22] <bzoltan1> Mirv: shorts did not pass here http://ci.ubuntu.com/smokeng/utopic/touch/mako/168:20140803:20140728.1/9448/?sort=pass_rate
[07:23] <jibel> ogra_, indicator-network is not visible on #171
[07:23] <jibel> that may explain test failures
[07:23] <ogra_> bzoltan1, don't trust the infrastructure to much, there are currently some issues
[07:23] <Mirv> bzoltan1: please do a comparison if you can "match" all your failures to those of #169, and also note which test is failing for shorts
[07:23] <ogra_> jibel, heh, definitely
[07:23] <bzoltan1> ogra_:  I figured... :(
[07:23] <sil2100> o/
[07:24] <ogra_> sil2100, 13 of the 15 crashes in the 171 tests are indicator-network ... and according to jibel it doesnt start in dogfooding
[07:24] <Mirv> bzoltan1: so you should probably have 4 calendar, 8 music-app, 9 address-book failures
[07:24] <ogra_> (just to sweeten your morning :) )
[07:24] <sil2100> 15 crashes?
[07:24] <ogra_> yeah, 171 has 15 crashes
[07:25] <ogra_> one dialer-app, one telepathy-ofono and 13 indicator-network ones
[07:25] <sil2100> It just can't get any better ;)
[07:25] <seb128> sil2100, hey
[07:25] <sil2100> seb128: hi
[07:25] <seb128> sil2100, the settings change you approved yesterday is incomplete, it should have an updated depends on the schemas since it uses keys that only got added to the new version
[07:26] <seb128> sil2100, can you get it fixed?
[07:26] <sil2100> seb128: I only top-approved it because mardy top-approved it, and the lander said it was all tested and fine
[07:26] <sil2100> I mean, mardy approved it
[07:26] <seb128> sil2100, well, you top approved and it's buggy, so you are responsible, sorry...
[07:26] <seb128> don't top approve if otherwise
[07:27] <seb128> if -> it
[07:27] <bzoltan1> Mirv: i have this for shorts http://paste.ubuntu.com/7958905/
[07:27] <sil2100> Chipaca: ping
[07:28] <Chipaca> sil2100: pong
[07:28] <sil2100> Chipaca: so it seems your landing wasn't completely +1
[07:28] <Chipaca> wha?
[07:29] <sil2100> Chipaca: check what seb128 mentioned above, the ubuntu-system-settings change that I was asking about seems to be missing something, something that mardy probably didn't see during his review
[07:29] <slangasek> sil2100: FYI, I didn't quite get autopilot-qt4 off the image yesterday; I've built a new one now that autopilot 1.5.0+14.10.20140716-0ubuntu2 is in
[07:29] <jibel> sil2100, ogra_ seb128 I filed bug 1352744
[07:29] <jibel> seb128, do you think the missing network-indicator is the same bug or should I submit another one?
[07:29] <seb128> jibel, likely the same bug
[07:29] <jibel> k
[07:29] <seb128> same as the segfaults
[07:30] <seb128> I wonder how that ofono could land it if creates those issues
[07:30] <seb128> it made things not work and tests from rdepends fail
[07:30] <ToyKeeper> Does this mean traincon 0?
[07:31] <sil2100> slangasek: ok, so you uploaded a new autopilot directly to the archive?
[07:31] <Mirv> bzoltan1: I built watch_only on your silo since the status was wrong in the sheet. the shorts app failure has happened on #161 (and random 1 failure every now and then otherwise) so probably not you to blame. please compare the 3 other packages with failures to the #169 results.
[07:31] <jibel> ToyKeeper, I guess it does, last promotion was 157 on July 29th
[07:31] <slangasek> sil2100: yes, with packaging-only changes and an MP raised on the 1.5 branch
[07:31] <Chipaca> sil2100: drat. I'll fix.
[07:31] <ToyKeeper> :(
[07:31] <sil2100> jibel, ToyKeeper: no, no traincon-0 yet, traincon is after 7 business days, now it's only 5... but we can decide on a traincon if things are very bad
[07:32] <bzoltan1> Mirv:  I am re-running the  calendar_app  music_app  address_book_app tests right now... takes damn long time
[07:32] <jibel> sil2100, k if it's business days
[07:32] <Chipaca> seb128: so do I bump the gsettings revno?
[07:32] <Mirv> bzoltan1: you don't need to rerun, you need to compare if you got the same failures as the #169 shows.
[07:32] <ogra_> slangasek, not sure you noted, but autopilot-qt4 is still on the image (was that wanted ?)
[07:33] <slangasek> ogra_: that's exactly the thing that I'm rebuilding for right now
[07:33] <bzoltan1> Mirv:  I have to, because the first run gave me more failures than the CO dash.. but then I started to run those tests individually and few of them turned to be OK. We have more flaky tests than the CI dash shows.
[07:33] <Chipaca> seb128: or do i use the autogenerated revno like the previous depends?
[07:33] <sil2100> Chipaca: thanks, would be grateful since I have many other things right now
[07:34] <Chipaca> sil2100: yeah, no worries
[07:34] <Mirv> bzoltan1: right, ok let's see to get slightly more certainty :( calendar and address book app tests are indeed quite slow
[07:35] <Chipaca> seb128: I mean, i can make it depend on the autogenerated
[07:35] <Chipaca> seb128: but i was told to land these things all together
[07:35] <bzoltan1> Mirv:  luckily I got the UITK silo build ready just before I went to sleep.. so the night test dropped out most of the time consuming tests with OK.. like unity8, uitk, browser, etc... so by the morning the list was down to the CI dash list.
[07:36] <Chipaca> seb128: which makes me wonder exactly how i was supposed to manage to do this dependency
[07:37] <sil2100> ogra_: I see that 170 also has many indicator-network crashes
[07:39] <sil2100> ogra_: I suppose it will be really hard to pin-down what caused those to happen so much
[07:40]  * sil2100 upgrades his phone
[07:45] <abeato> jibel, ping
[07:46] <jibel> abeato, pong
[07:46] <abeato> jibel, hi, so why do you think it is an ofono issue?
[07:47] <jibel> abeato, http://people.canonical.com/~ogra/touch-image-stats/170.changes the most probable change in this list is ofono
[07:48] <tvoss> sil2100, likely an issue with ofono not exposing a certain type of interface early enough
[07:48] <ogra_> jibel, what is broken in 170 ?
[07:48] <ogra_> looks pretty good on my device here
[07:49] <abeato> jibel, ok, I am going to re-flash mako, I do not see the issue for #171 in krillin
[07:49] <jibel> ogra_, bug 1352744
[07:50] <ogra_> hmm, i dont see that in 170
[07:51] <jibel> ogra_, ah, I'm lost in build numbers :) let me reflash 170 then 171
[07:52] <ogra_> in smoketesting the indicator crashes in 170 ... but thats in its normal range (5 crashes ... not 13)
[07:52] <ogra_> "normal" :P
[07:53] <sil2100> Yeah
[07:53] <sil2100> ogra_: but it would be best if we had someone see if 170 doesn't have it completely broken as well, just in case
[07:54] <bzoltan1> Mirv:  for the calendar app I got +1 failure... after re-running that +1 it failed again (could not even start the app), I rebooted and then that test passed. So the calendar is as good with the UITK as on the CI dash. I proceed with the next one...
[07:54] <ogra_> sil2100, i'm running 170 here ... (on some other device)
[07:54] <ogra_> there it is fine
[07:55] <sil2100> ogra_: yeah, but it seems to be mako specific - flo and manta do not have so many crashes on 171
[07:55] <sil2100> So I wonder
[07:55] <ogra_> weird
[07:55] <ogra_> android didnt change
[07:55] <sil2100> Let's see what jibel finds out :)
[07:56] <ogra_> (it will change with the next build)
[07:58] <jibel> ogra_, if I want to backup a mako before wiping it (it is my main phone) is saving /home enough? or should I backup all the rw partitions? (I don't care about keeping logs and this type of data)
[07:59] <ogra_> jibel, phew, not sure, i usually just pull my data off via mtp and do a fresh flash later ...
[08:00] <ogra_> i never tried to backup the rw partitions ... if you dont miss anything that might work though
[08:00] <jibel> i'll try and see what I lose
[08:01]  * ogra_ wishes gallery app would start :(
[08:01] <ogra_> i reflashed yesterady and cant set my lockscreen wallaper now :(
[08:01] <sil2100> ogra_: gallery app does not work at all?
[08:02] <sil2100> Or doesn't work only when during content picker?
[08:02] <ogra_> sil2100, not sure ... it doesnt start at all for me
[08:02] <slangasek> sil2100, ogra_: ok, Qt4 off the image now; 11MB savings in tar.gz size, dunno how much savings on the install footprint
[08:03] <slangasek> and hopefully, removed without any test regressions
[08:03] <ogra_> lets take bets :)
[08:03]  * ogra_ says 60MB
[08:03] <slangasek> :)
[08:03] <sil2100> hah ;)
[08:03] <sil2100> slangasek: thanks!
[08:03] <ogra_> yeah !!
[08:05] <sil2100> hm, we'll have to poke veebers or thomi to rebuild the autopilot silo though
[08:05] <sil2100> I might do it for them if they're not around though
[08:05] <thomi> hmmm?
[08:05] <Chipaca> sil2100: https://code.launchpad.net/~chipaca/ubuntu-system-settings/gsettings-schema-depends-fix/+merge/229567
[08:06] <pete-woods> sil2100: you're a legend! thanks for fixing up the changelog for release:)
[08:07] <sil2100> pete-woods: nooo ;p No problem, good thing that I had access to that team and could commit to staging
[08:07] <slangasek> sil2100: ah, time-of-day suggests thomi is probably not around, I guess we should take care of this for tem
[08:07] <slangasek> them
[08:07] <thomi> ...
[08:07] <sil2100> Yeah, will do that in a moment :)
[08:07] <thomi> I'm around
[08:07] <sil2100> thomi: no worries! No re-testing needed, it's just a packaging change
[08:13] <bzoltan1> Mirv:  the music app is cleared too. The CI dash shows 8 failures and the UITK gave 9. The +1 was the music_app.tests.test_music.TestMainWindow.test_add_song_to_queue_from_albums_page what was OK after I run only that one again.
[08:13] <Chipaca> seb128: https://code.launchpad.net/~chipaca/ubuntu-system-settings/gsettings-schema-depends-fix/+merge/229567
[08:15] <sil2100> Chipaca: could you fix the issue I mentioned? i.e. 0.0.2+14.10.20140802.1 instead of 0.0.2+14.10.20140802 as the version
[08:15] <sil2100> Chipaca: it's a nit-pick, but since we fix it up now anyway, let's have the correct thing
[08:15] <Chipaca> sil2100: i didn't see you mention that, yes sure
[08:15] <sil2100> Chipaca: I just noticed it and mentioned ;)
[08:16] <sil2100> (you might have needed to refresh the page)
[08:16] <jibel> ogra_, sil2100 abeato I confirm that 1352744
[08:16] <jibel> is a regression in #170
[08:16] <sil2100> Uh
[08:16] <abeato> jibel, I have just commented in https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1352744
[08:16]  * sil2100 looks at the commitlog
[08:16] <Chipaca> sil2100: done
[08:17] <sil2100> jibel: ok, thanks, then it might be the ofono upload then indeed
[08:17] <abeato> jibel, sil2100 the crash happens when indicator-network tries to access a non-existing interface
[08:17] <abeato> SimManager, when there is no SIM
[08:17] <sil2100> abeato: oh
[08:17] <abeato> jibel, can you confirm that you have no SIM inserted=
[08:17] <abeato> ?
[08:17] <jibel> abeato, confirmed
[08:18] <abeato> hm, weird thing, ofono has not changed its behaviour with regard to when the interfaces appear
[08:18] <bzoltan1> Mirv:  the address book app has exactly the same failures on CI dash as with the UITK silo tests
[08:19] <sil2100> abeato, jibel: makes sense, the indicator works fine here on my mako with a sim inserted
[08:19] <abeato> but imho this should be sorted out in indicator-network
[08:20] <zbenjamin> ogra_: is there any problem with the 174 emulator image? http://pastebin.ubuntu.com/7959173/
[08:21] <sil2100> abeato, jibel, ogra_: in any case, I informed mandel who was the lander for the ofono landing about the regression
[08:21] <bzoltan1> sil2100:  Mirv: I have flipped the UITK landing to be tested. I did see shitload of failures but nothing what is not failing on the CI dash already. The shorts have the shorts_app.tests.test_rssreader.TestMainWindow.test_open_listmode_feed_item failing
[08:22] <sil2100> bzoltan1: ACK, we'll try landing this today then, thanks for your hard work in testing it throughly :)
[08:23] <bzoltan1> sil2100:  I am just doing my job :)
[08:23] <bzoltan1> sil2100: I am checking that shorts failure just to be super sure...
[08:24] <jibel> 172 already, did we switch to 1 build per hour :)
[08:26] <ogra_> heh
[08:28] <abeato> jibel, sil2100, ogra_ the only thing that could have triggered this bug is that now there are a couple of interfaces that were not there previously when there was no SIM, which maybe confuses indicator-network
[08:28] <Mirv> bzoltan1: it seems good to me, then, as good as can be testable under the circumstances.
[08:29] <bzoltan1> Mirv:  yes, the shorts app failure we are investigating with kalikiana, to be hypersure. But i think this UITK is good to go.
[08:29] <Mirv> bzoltan1: https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/landing_08-04/+merge/229487 not approved
[08:30] <abeato> Wellark, ping
[08:30] <bzoltan1> Mirv:  ohh.. again I forget ... sorry, approved
[08:35] <Mirv> bzoltan1: ^ -gles missing
[08:37] <Mirv> bzoltan1: are you on it, or do you want to me to try it?
[08:38] <bzoltan1> Mirv:  no need, I captured it. There is a bug in the shorts tests...we are on it
[08:39] <Mirv> aha, ok
[08:41] <Mirv> rsalveti: can you ack https://ci-train.ubuntu.com/job/landing-015-2-publish/40/artifact/packaging_changes_messaging-app_0.1+14.10.20140804-0ubuntu1.diff (you tried to publish it before but didn't ack the changes)?
[09:00] <Chipaca> anybody around here know what a GhostRevisionsHaveNoRevno error from bzr means? or more pointedly, how to fix it?
[09:04] <oSoMoN> sil2100, good morning! can I have a silo for line 42, please?
[09:05] <sil2100> oSoMoN: hello! Let me take a look at that :)
[09:36] <Mirv> bzoltan1: I put the testing status back to No until you're ready
[09:36] <bzoltan1> Mirv:  OK
[09:37] <Mirv> maybe ogra_ could ack this? https://ci-train.ubuntu.com/job/landing-015-2-publish/40/artifact/packaging_changes_messaging-app_0.1+14.10.20140804-0ubuntu1.diff
[09:37] <Mirv> since ricardo seems away
[09:37] <Mirv> does not seem rocket science level of pkging changes
[09:44] <jibel> psivaa, can you remind me the bug # for precise alternate installation failure ?
[09:45] <psivaa> jibel: https://bugs.launchpad.net/ubuntu/+source/xorg-lts-transitional/+bug/1351262
[09:46] <jibel> psivaa, thanks
[09:47] <Laney> Mirv: that is like the worst changelog
[09:48] <Laney> it's impossible to assess these changes in isolation
[09:55] <mandel> sil2100, you might be able to give me a hand, I'm getting the following when executing debuild -uc -uc
[09:55] <mandel> sil2100, dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at
[09:55] <mandel> sil2100, but I've never had that issue, any idea?
[09:57] <Mirv> indeed the changelog does not explain the additional dep (or cmake changes)
[09:59] <sil2100> mandel: hi! For what project does that happen? If you're doing it for some of our upstream projects then you need to make sure the tarball is  there, as it's being generated by bzr
[09:59] <mandel> sil2100, I'm doing it for the location-service, AFAIK nothing has changed we only bumped the version
[10:00] <sil2100> mandel: try running bzr bd first to generate the tarball
[10:00] <popey> ooh! screen wakes on alarms
[10:03] <seb128> Mirv, that diff has a buggy indentation, using a tab in the build-depends which is space indented
[10:06] <mandel> sil2100, strange bzr bd works
[10:06] <sil2100> mandel: bzr bd will always work as how our ubuntu projects work is:
[10:07] <sil2100> mandel: the tarball is generated from the bzr tree by using the split option, so bzr bd actually generates the upstream tarball from the source on every build
[10:08] <tvoss> mandel, we changed the source format
[10:08] <sil2100> mandel: without bzr bd, debuild has no knowledge about how to generate the tarball, so it will fail if it doesn't find it already generated
[10:08] <mandel> tvoss, ah, I missed that
[10:08] <mandel> sil2100, ok, thx
[10:11] <Mirv> renatu: see seb's and laney's comments regarding landing-015
[10:12] <Mirv> if renatu is renato, that is :) bill and boiko not around
[10:16] <popey> psivaa: can you please trigger https://code.launchpad.net/~bzoltan/ubuntu-rssreader-app/select_many/+merge/229590 to do the jenkins dance?
[10:19] <psivaa> popey: let me take a look
[10:20] <popey> thanks psivaa
[10:21] <bzoltan1> Mirv:  We got the shorts app failure. the Shorts app needs a single line change to make it OK -> https://code.launchpad.net/~bzoltan/ubuntu-rssreader-app/select_many/+merge/229590 popey promised to take care of it.
[10:21] <davmor2> popey: do you have the youtube scope enabled?
[10:21] <davmor2> installed even
[10:22] <popey> yes
[10:22] <davmor2> popey: if you select anything does it play ever?
[10:22] <popey> oh, i thought i did, but i dont
[10:23] <popey> where'd that go
[10:23]  * popey installs
[10:23] <davmor2> popey: also if you try swiping the resulting youtube video window from right to left to close it does it jolt back and then not be able to swipe away
[10:25] <popey> davmor2: youtube playback appears to be broken in the browser
[10:27] <sil2100> Ok, for a moment I thought dogfood was down
[10:27] <davmor2> popey: works fine from your app though
[10:27] <Mirv> bzoltan1: excellent!
[10:27] <sil2100> But then I noticed that the internet is down
[10:27] <sil2100> duh
[10:28] <popey> davmor2: yeah, you're right
[10:28] <popey> odd
[10:29] <davmor2> popey: so I don't think it is the playback that is broken I think it is the direct link format it is using
[10:29] <popey> well the video playbox box appears
[10:31] <davmor2> popey: yeah but no fullscreen button and the sound is muted and it doesn't play, so I'm wondering if it is linking to the flash version instead of the html5 versions maybe as a huge guess
[10:31] <popey> unlikely as the video render box appears
[10:32] <popey> hmm, going to m.youtube.com in the browser works
[10:32] <popey> i wonder if its adverts that aren't playing
[10:32] <davmor2> popey: could be
[10:33] <davmor2> popey: it is definitely something specific to the video url that is produced from the scope
[10:34] <bzoltan1> Mirv:  may I get a silo for the QtC plugin?
[10:34] <popey> davmor2: shelling in to get the url it launched with...
[10:35] <popey> webbrowser-app https://www.youtube.com/watch?v=7-7knsP2n5w  for me
[10:35] <popey> that video clearly works on desktop
[10:35] <popey> has no adverts for me here (no adblock)
[10:35] <bzoltan1> Mirv:  line 43
[10:42] <Mirv> bzoltan1: done
[10:43] <bzoltan1> Mirv:  thanks
[10:45] <davmor2> popey: I just dropped that line into my utopic desktop and I got The Adobe Flash Player is required for video playback, get the latest flash player
[10:46] <davmor2> popey: as in the whole of webbrowser-app https://www.youtube.com/watch?v=7-7knsP2n5w that line
[10:46] <popey> so maybe a video that's not available in html5?
[10:46] <bzoltan1> Mirv:  So, what is the plan with the UITK landing?
[10:48] <davmor2> popey: works fine via your app
[10:50] <davmor2> popey: so I think the issue is that the link is to the desktop flash version,  I wonder if there is a way to find the url from your app and compare it
[10:51] <popey> well, the test would be to try and play the same video in the app
[10:52] <popey> ok, tested that, found that video in my app and it plays fine
[10:54] <davmor2> popey: there is no m. at the start of the link, I bet the scope is basically presenting itself as though it were a desktop app not a mobile one
[10:54] <popey> well its the browser really
[10:54] <popey> not the scope
[10:55] <popey> i dunno ☻
[10:55] <Mirv> bzoltan1: step 1 is someone setting it back to tested :)
[10:55] <davmor2> popey: well I'm assuming that the scope is say open to this link
[10:56] <davmor2> popey: meh no it does show as m.youtube.com so that blew that theory out of the window
[10:57] <bzoltan1> Mirv:  Ohh... i can be that someone :)
[10:57] <popey> psivaa: any luck with https://code.launchpad.net/~bzoltan/ubuntu-rssreader-app/select_many/+merge/229590 ?
[10:58] <psivaa> popey: i added bzoltan in the the jenkins instance as allowed user. that should trigger the job. it hasn't triggered yet. digging  more on this
[10:58] <popey> thanks
[11:01] <Mirv> not really, just the automated gles watch thing
[11:02] <psivaa> popey: sorry about that. i had a typo earlier. the job has triggered
[11:04] <psivaa> popey: as you might have seen.. that MP needs some fixing
[11:11] <brendand> sil2100, is the messaging-app failure not a known issue?
[11:11] <brendand> sil2100, it's been reproducible for a while
[11:11] <sil2100> brendand: not sure - is it reproducible locally?
[11:11] <brendand> sil2100, yes
[11:11] <brendand> sil2100, been failing consistently since 165 on friday
[11:12] <brendand> no wait, that was last monday actually
[11:12] <davmor2> brendand: is this the issue for the icon missing or something?
[11:12] <brendand> davmor2, yeah
[11:17] <brendand> davmor2, is there a bug for it? is someone looking at it?
[11:17] <davmor2> brendand: pass sil2100 ^  is there a bug for that?
[11:21] <Chipaca> sil2100: don't forget https://code.launchpad.net/~chipaca/ubuntu-system-settings/gsettings-schema-depends-fix/+merge/229567 when you have a gap (hah)
[11:22] <sil2100> brendand: davmor2: uh, we might have 'missed' it in all this commotion, let me poke boiko as soon as he's up - but it might be fixed by the landing they prepared as well
[11:23] <sil2100> As he mentioned some things in other apps as well
[11:23] <sil2100> Chipaca: sure :)
[11:24] <brendand> sil2100, which silo is that? i can try it out
[11:25] <sil2100> brendand: let me see
[11:25] <sil2100> brendand: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-015
[11:25] <brendand> sil2100, cool
[11:25] <sil2100> brendand: this is ready for landing actually, so I'll publish this in a moment anyway :)
[11:25] <brendand> sil2100, it's also meant to fix address book?
[11:25] <sil2100> Yes
[11:25] <sil2100> At least from what boiko said ;)
[11:32] <Mirv> sil2100: seb + lane_y had comments about the packaging changes
[11:32] <Mirv> on that one
[11:32] <sil2100> Ok, didn't look at those yet as I still didn't finish something else
[11:34] <Mirv> I added the comments to the sheet
[11:43] <bzoltan1> ogra_: I have a new API for the seeds -> https://code.launchpad.net/~bzoltan/ubuntu-seeds/add_settings/+merge/229602
[11:44] <sil2100> grrrr
[11:45] <renatu> Mirv, the only problem on silo15 is the indention? or there is any other problem?
[11:46] <renatu> Mirv, fix pushed
[11:47] <Mirv> renatu: the changelog (=commit message) also doesn't explain the cmake file changes or the additional new build dependency
[11:48] <renatu> Mirv, how I can fix that? can I edit the changelog manually?
[11:49] <Mirv> renatu: you change the merge request's commit message
[11:49] <renatu> ok
[11:49] <Mirv> renatu: for example https://code.launchpad.net/~renatofilho/address-book-app/release-2014-08-04/+merge/229528 now only has "Visual update"
[11:55] <renatu> Mirv, I have updated the messaging mr commit message
[11:56] <renatu> Mirv, the address-book-app only contains visual updates, more details about the changes can be found in each commit message
[11:59] <ogra_> sil2100, looks like android is in the archive, if you dont have anything pending i'll start a build now
[11:59] <sil2100> hmm
[11:59] <sil2100> ogra_: one moment
[11:59] <ogra_> ok
[12:00] <sil2100> Mirv: so, what were the comments from seb regarding the address-book etc. landing?
[12:00] <Saviq> sil2100, recon on silo 7 please, added qtmir-gles
[12:01] <sil2100> Saviq: ACK
[12:06] <Mirv> sil2100: see sheet, renato is now fixing them. cosmetic+reviewability
[12:12] <sil2100_> Saviq: sorry, internet problems... did anyone reconfigure in the meantime?
[12:13] <popey> pete-woods: youtube scope approved to store..
[12:13] <pete-woods> popey: thanks!
[12:14] <tvoss> sil2100_, any plans to spin an image with the language pack updates in? dist-upgrading the device is taking ages right now
[12:14] <sil2100_> ogra_: ok, could you kick a new image ;)?
[12:15] <sil2100_> ogra_: I guess it's the right time now
[12:15] <Saviq> sil2100_, nope
[12:15] <jhodapp> Mirv, land line 27 first
[12:15] <sil2100_> Saviq: ok, reconfiguring then
[12:15] <ogra_> sil2100_, you mean to make the peopple using unsupported upgrade methods happy ?
[12:16]  * ogra_ bets when tvoss just waits for dist-upgrade to finish he will still be twice as fast as the image builder :)
[12:16] <tvoss> ogra_, exactly, those developers trying to move as fast as possible
[12:16] <tvoss> ogra_, sure, not questioning that
[12:17] <tvoss> ogra_, it's not only me waiting for language pack installations finishing righ tnow
[12:17] <ogra_> sil2100_, ugh, i cant !
[12:17] <ogra_> stgraber, iso tracker is not offering me a build button ...
[12:17] <cjwatson> bet you aren't logged in
[12:18] <ogra_> i am
[12:18] <ogra_> (guessing by the "log out" button next to my name in the top right)
[12:18] <ogra_> ;)
[12:18] <cjwatson> I get the usual checkboxes and "Request a rebuild"
[12:18] <cjwatson> So I can kick it for you if you like
[12:18] <ogra_> yes please ... though i would like to be able to do it myself without having to use nusakan
[12:18] <ogra_> :/
[12:19] <cjwatson> done
[12:19] <ogra_> thx
[12:20] <ogra_> aha !
[12:20] <ogra_> SSO was nice enough to uncheck the ubuntu-touch-imagebuilders membership for me :P
[12:21] <ogra_> that was checked last week ! silly thing
[12:22] <slangasek> sil2100_: so, any sign of new issues with the qt4 removal?  Or is it hard to tell because of masking by the general networking problems?
[12:23] <Mirv> jhodapp: ok, you have silo now for that
[12:24] <jhodapp> Mirv: thanks
[12:25] <imgbot> [12:25] <brendand> sil2100_, yeah silo15 fixes it :)
[12:26] <renatu> sil2100_, Mirv , do you need any other fix?
[12:26] <popey> bzoltan1: approved your branch, when it lands we'll ship a new shorts to the store
[12:26] <renatu> sil2100_, Mirv can we land this in the next image?
[12:26] <ogra_> slangasek, heh, well, hard to tell since the results are currently so broken that we essentially are flying blind
[12:26] <ogra_> slangasek, the apparmor denials make the world explode
[12:26] <bzoltan1> popey: Thank you very much
[12:26] <popey> np
[12:26] <slangasek> ogra_: ack
[12:27] <bzoltan1> popey: and by the way. We will have a permanent solution from the UITK to avoid similar problems in the future.
[12:36] <Mirv> renatu: did you fix the LP pages' "commit message" fields for all MPsbto be more descriptive? (explaining packaging / makefile changes to make them reviewable in the packaging diff)
[12:40] <popey> bzoltan1: great!
[12:42] <renatu> Mirv, done
[12:44] <sergiusens> jibel: ogra_ for what it's worth, I had indicator-network crashing ever since I was on the road last Wednesday; failed to start
[12:44] <ogra_> sergiusens, ouw !
[12:45] <Saviq> davmor2, hey, would you have time to do QA sign off on silo 7?
[12:45] <sergiusens> ogra_: my process was; open terminal and: "start indicator-network"
[12:46] <ogra_> heh
[12:47] <sil2100_> psivaa: hey, were you able to re-run those tests in 171?
[12:48] <sil2100> slangasek: so, from what I see things seem to be a bit brokenish...
[12:48] <ogra_> lol
[12:48] <sil2100> ogra_: did you see test results for 172 :/ ?
[12:48] <ogra_> diplomat !
[12:48] <ogra_> sil2100, "totally screwed" would be my expression :)
[12:48] <sil2100> ;)
[12:49] <sil2100> I personally don't feel like looking at the dashboard right now
[12:50] <Mirv> renatu: thanks, looks very good now! I'm doing a quick rebuild, after that a smoke test should be done (no code changes) and someone of you landers should set the silo back to "Testing pass?" "Yes" for publishing.
[12:51] <renatu> oSoMoN, could you do that ^^
[12:51] <renatu> Mirv, thanks
[12:52] <psivaa> sil2100: hmm, weird. by the time the tests kicked off, 172 must have been available. the job picked up 172 :/
[12:52] <psivaa> sil2100: if you'd like the same ones with 171 i could rerun them again. sorry dint notice this 172 being on the way
[12:53] <sil2100> cjwatson: hi! Could you by any chance branch lp:~sil2100/cupstream2distro/cu2d-rtm again on snakefruit? I added a ton of other workarounds to enable it working for both DF and LP simultaneously
[12:53] <sil2100> psivaa: yeah, if you could do it for 171 it would be awesome, as 172 is b0rken badly
[12:54] <psivaa> sil2100: will do
[12:54] <sil2100> psivaa: thanks :)
[12:55] <cjwatson> sil2100: done
[12:58] <davmor2> Saviq: I'm just back from Lunch.  Give me a few minutes to just look and see if anyone has got back to me with anything and then I'll happily have a look for you
[12:58] <Saviq> davmor2, great, thanks
[13:01] <sil2100> cjwatson: thanks!
[13:06] <sil2100> Mirv: if you publish anything, remember to lookout for issues with package uploads to the archive ;)
[13:06] <sil2100> Mirv: the copy2distro I made is a big hack right now, as I didn't want to modify the other code-paths
[13:10] <Mirv> sil2100: seems to have worked so far
[13:12] <ogra_> hacks ... the glue that holds the world together
[13:12] <ogra_> :)
[13:13] <oSoMoN> renatu, sorry, I’m lacking context, what do you need?
[13:13] <psivaa> slangasek: we're having whoopsie test in default set for some images now: http://ci.ubuntu.com/smokeng/utopic/touch/mako/172:20140805.1:20140728.1/9490/default/1486871/
[13:14] <renatu> oSoMoN, I need you to mark silo 15 as Yes for testing pass
[13:14] <psivaa> slangasek: curious if you'd know what caused it?
[13:14] <oSoMoN> renatu, have you actually tested it according to the test plan?
[13:17] <renatu> oSoMoN, yes
[13:17] <psivaa> slangasek: ok, I think you could ignore me: i see https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1351137 is the reason for it from the comments
[13:17] <oSoMoN> renatu, ok, will do in a moment
[13:17] <renatu> oSoMoN, Thanks
[13:20] <slangasek> psivaa: ah, I would have expected that test to be working.  Do the devices get reflashed for each test?
[13:20] <slangasek> psivaa: or are they upgraded?
[13:20] <slangasek> psivaa: I do want the test to actually be passing ;)
[13:21] <psivaa> slangasek: they are flashed every time at least before the default tests
[13:21] <slangasek> ok, good
[13:21] <slangasek> good that you're doing this; bad that whoopsie_upload_all is apparently still not running
[13:28] <bzoltan1> Mirv: sil2100: the silo8 is good to go
[13:29] <sil2100> bzoltan1: publishing :)
[13:29] <Mirv> publish.. not
[13:29] <Mirv> sil was too fast, again :)
[13:29] <psivaa> slangasek: looks like it's running but not within 20 seconds
[13:29] <slangasek> psivaa: this is highly improbable
[13:30] <slangasek> psivaa: it's inotify-driven, and creating the .upload files is a quick operation
[13:30] <slangasek> I tested the script locally in an environment here on a device that did have /var/lib/apport/autoreport, and it was near instantaneous
[13:31] <psivaa> slangasek: ok, not sure why the delay was.. but it took more than 20 seconds for me to see whoopsie-upload-all to run after i sent the -SEGV kill signal
[13:32] <slangasek> psivaa: yes, but the delay is between sending the signal and the creation of the .crash file, not between creation of the .crash file and creation of the .upload file
[13:32] <slangasek> psivaa: it should never take more than a second to create the .upload file for the .crash file
[13:33] <slangasek> and here, even the .crash file was created within 2 seconds
[13:37] <psivaa> slangasek: it's taken more than 20 sec again here. would it be different if the crash is on unity8?
[13:37] <psivaa> and i saw the .crash appearing instantaneously
[13:37] <slangasek> psivaa: whoopsie_upload_all should still be quick
[13:37] <slangasek> psivaa: oh
[13:38] <boiko> sil2100: sorry, I tested everything yesterday, but forgot to mark the silo as tested, just did it
[13:38] <slangasek> psivaa: that implies that the .crash is not being created atomically
[13:38] <slangasek> psivaa: let me dig
[13:38] <brendand> sil2100, psivaa - what's happening with the ci results? did the rerun not have any effect?
[13:38] <psivaa> slangasek: let me paste the ls -lart details
[13:38] <sil2100> brendand: what do you mean?
[13:38] <sil2100> brendand: it's still re-running 171, but 172 is completely b0rken
[13:39] <brendand> sil2100, oh right. because of the network?
[13:39] <sil2100> brendand: no, 172 might be b0rken becasue of qt4 being gone I suppose...
[13:40] <sil2100> hah!
[13:41] <boiko> sil2100: oh, wait, I think I I marked the silo as tested, renatu just told me he fixed some more things, so I'll be testing again
[13:42] <psivaa> sil2100: brendand with 171 rerun the results are still running: http://ci.ubuntu.com/smokeng/utopic/touch/mako/171:20140805:20140728.1/9484/ improvement i guess
[13:42] <sil2100> boiko: I think some core-devs had some packaging issues
[13:43] <stgraber> ogra_: yeah, sso is a bit weird, never quite got how it decided what to keep selected
[13:43] <ogra_> stgraber, yeah, i thought if i had it selected it once it keeps it
[13:43] <ogra_> seems not :P
[13:44] <davmor2> Saviq: right installing now I'll get back to you in an hour or so
[13:46] <brendand> sil2100, because of qt4 being gone?
[13:46] <ogra_> unlikely
[13:47] <ogra_> the 100s of apparmor denials and non-working network are more likely i think
[13:47] <sil2100> brendand: 172 dropped qt4 packages, that was the biggest change... but not sure about that - what we know for sure is that it's horrible ;p
[13:47] <Saviq> davmor2, awesome, thanks
[13:48] <jdstrand> ogra_: what is causing the 100s of apparmor denials?
[13:48] <brendand> sil2100, there appear to be a whole load of dbus errors
[13:48] <ogra_> jdstrand, same issues still
[13:48] <jdstrand> autopilot?
[13:48] <ogra_> jdstrand, yeah, dbus introspection errors from autopilot
[13:49] <jdstrand> I wonder if plars got his changes pushed out in those tests
[13:49] <ogra_> i hope plars was able to collect some info with your changes from yesterday
[13:49] <jdstrand> ogra_: can you point me at a log?
[13:49] <ogra_> jdstrand, https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/657/consoleFull
[13:50] <ogra_> after all the syslog or console log of most of the red ones on http://ci.ubuntu.com/smokeng/utopic/touch/mako/172:20140805.1:20140728.1/9490/
[13:52] <jdstrand> I see the output from aa-clickhook. it didn't crash and exited properly and the rules are applied based on adb-shell /home/phablet/bin/check-clickhook-rules
[13:52] <jdstrand> ADB_RC=0
[13:54] <bzoltan> sil2100: thank you
[13:54] <plars> jdstrand: I pushed the changes into our scripts,  but the phablet-config one hasn't landed yet
[13:55] <plars> jdstrand: did it happen again?
[13:55] <jdstrand> so I'm told
[13:55] <jdstrand> I'm looking now
[13:56] <plars> jdstrand, ogra_: if you grep the log for check-clickhook-rules, you'll see where the checks run
[13:56] <plars> jdstrand: the log ogra_ posted doesn't seem to have any failures on it though
[13:56] <jdstrand> I don't see autopilot denials
[13:57] <jdstrand> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/657/ has failures, but they aren't autopilot
[13:57] <jdstrand> so, there is the known gallery and notes denials
[13:57] <psivaa> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/653/artifact/clientlogs/camera_app/syslog/*view*/ has the denials
[13:58] <jdstrand> the media-hub denials
[13:58] <jdstrand> then
[13:58] <jdstrand> but those should be fixed in the latest mediahub
[13:58] <jdstrand> let me check that
[13:59] <jdstrand> that build doesn't seem to have media-hub 1.0.0+14.10.20140731-0ubuntu1
[14:01] <jdstrand> that ^ may be the cause of the music-app failures
[14:02] <psivaa> jdstrand: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/658/consoleText also has denials corresponding to camera and clock app tests on 172
[14:02] <psivaa> jdstrand: hang on pls. wrong link
[14:03] <psivaa> jdstrand: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/656/artifact/clientlogs/ubuntu_terminal_app/syslog/*view*/
[14:03] <psivaa> is the right one sorry
[14:04]  * jdstrand wonders why the log goes back to Jan 7
[14:05] <imgbot> [14:05] <imgbot> [14:05] <davmor2> popey: hmmm In calendar app I see something weird.  In month view I see Dots for appointments in July, I also see them for September but August is blank
[14:05] <jdstrand> plars: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/656/artifact/clientlogs/ubuntu_terminal_app/syslog/ has autopilot denials
[14:06] <brendand> sil2100, want me to check out the autopilot/dbus issues?
[14:06] <sil2100> brendand: if you could help out with that it would be excellent!
[14:07] <plars> jdstrand: I don't see any check-clickhook-rules failures there though
[14:07] <brendand> sil2100, ok i'll have a look and see what i can find
[14:07] <jdstrand> no, me either
[14:07] <brendand> sil2100, it's new in 172 right?
[14:09] <Mirv> Laney: ack request renewed, https://ci-train.ubuntu.com/job/landing-015-2-publish/lastSuccessfulBuild/artifact/packaging_changes_messaging-app_0.1+14.10.20140805-0ubuntu1.diff
[14:10] <jdstrand> plars: if I look in https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/656/consoleFull, and search for 'testing ubuntu_clock_app'
[14:11] <jdstrand> plars: where is the check-clickhook-rules check before it?
[14:12] <brendand> sil2100, it seems to be only click packages affected
[14:12] <davmor2> Saviq: with silo 007 in place why would the videos scope carousel stop displaying video snapshots?  They are just blank grey tiles with a title now
[14:13] <brendand> sil2100, maybe something broke in the --enable-dbus-probe tool
[14:13] <jdstrand> plars: it seems like it goes from dropping letters to clock-app, but we don't verify the click rules are in effect when the clock app starts
[14:13] <Saviq> davmor2, anything relevant in .cache/upstart/unity8-dash.log ?
[14:13] <Saviq> davmor2, sounds like the thumbnail generation failed
[14:13] <sil2100> brendand: then it might most possibly be the same issue we've been seeing already - I see jdstrand and plars are looking into it all the time
[14:14] <jdstrand> oh
[14:14] <jdstrand> plars: under 'testing ubuntu_clock_app' there is a 'reboot'
[14:14] <davmor2> Saviq: the thumbnails are then in the video view where they are nolonger in carousel
[14:16] <jdstrand> plars: oh no, I see after the reboot there is a /home/phablet/bin/check-clickhook-rules
[14:16] <plars> jdstrand: yeah, sorry I'm in a meeting right now. It reboots before each new testsuite
[14:17] <plars> jdstrand: which reruns the setup steps like phablet-config
[14:17] <jdstrand> plars: yeah, disregard that
[14:19] <jdstrand> seems like somewhere between adb-shell /home/phablet/bin/check-clickhook-rules and 10:19:58.379 ERROR proxies:410 - Introspect error on :1.74:/com/canonical/Autopilot/Introspection: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender=":1.72" (uid=32011 pid=3746 comm="/usr/bin/python3 -m autopilot
[14:19] <davmor2> Saviq: http://paste.ubuntu.com/7961520/
[14:19] <jdstrand> plars: I have to step into a meeting, but can you give me a link to check-clickhook-rules?
[14:20] <Wellark> sil2100: did you have something for me?
[14:20] <Saviq> davmor2, there's only one 'D-Bus error:  "Could not get thumbnail"'
[14:20] <plars> jdstrand: here's the mp from yesterday that shows pretty clearly the change I made yesterday: https://code.launchpad.net/~pwlars/ubuntu-test-cases/touch-add-aa-clickhook-check/+merge/229513
[14:20] <Saviq> ah but that's for albums anyway
[14:20] <Saviq> davmor2, I'll need to have a look
[14:20] <sil2100> Wellark: hello! Most probably, yes, as indicator-network is having issues in our current images
[14:21] <sil2100> Wellark: I suppose you are the right person to poke about this? :)
[14:21] <Wellark> this one? https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1352744
[14:21] <sil2100> Wellark: it seems that after the last ofono update bug LP: #1352744 appeared
[14:21] <Wellark> yeah. ok. I will investigate
[14:21] <sil2100> Wellark: yes, it seems to segfault whenever the simcard is not inserted :)
[14:21] <sil2100> Wellark: thanks!
[14:22] <Wellark> actually there might be two bugs in that one
[14:22] <Wellark> anyway.
[14:22] <Wellark> I'll start triaging
[14:23] <davmor2> Saviq: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-08-05-152139.png  vs  http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-08-05-152222.png
[14:28] <popey> the contacts ui seems to have broken recently
[14:28] <sil2100> Wellark: it might, we also saw many indicator-network crashes during smoketesting, which is using the ofono-phonesim-autostart
[14:28] <sil2100> Wellark: just so you know
[14:28] <davmor2> popey: how so?
[14:29] <sil2100> People! Stop breaking things!
[14:29] <popey> oh jees, this image is bad
[14:29] <sil2100> popey: 173?
[14:29] <popey> yes
[14:29] <ogra_> blame tvoss
[14:29] <davmor2> popey: other than the image being slightly bigger and closer to the first letter
[14:29] <ogra_> he asked for ti
[14:29] <ogra_> *it
[14:30] <popey> http://imgur.com/EnFvIP8
[14:30] <sil2100> Well, it also has a new UITK
[14:30] <popey> text alignment is all wrong
[14:30] <Wellark> sil2100: ack
[14:30] <sil2100> popey: I think we need to blame bzoltan for that!
[14:30] <sil2100> bzoltan: confess!
[14:30] <popey> the clicks store has white arrow in the title
[14:30] <popey> http://imgur.com/9C5elck
[14:31] <popey> and white search icon
[14:31] <sil2100> bzoltan, t1mp: could you take a look at the issues that popey is mentioning above ^ ?
[14:33] <brendand> sil2100, hmm - so i don't have a problem after i run 'phablet-config autopilot --dbus-probe enable'
[14:33] <brendand> sil2100, are psivaa/plars sure that somehow didn't fail to run?
[14:33] <brendand> sil2100, because it certainly looks like it
[14:33] <sil2100> I think there was some lead once that something could have getting in the way with that
[14:34] <ogra_> brendand, well, the consolelog should have the full info
[14:34] <ogra_> (just hard to read there)
[14:35] <brendand> ogra_, it does say it runs that
[14:35] <brendand> ogra_, multiple times for some reason (maybe once per suite)
[14:36] <brendand> although that's unneccesary
[14:36] <ogra_> yep
[14:36] <ogra_> one per suite
[14:36] <ogra_> it should also show the return value iirc
[14:36] <ogra_> or at least spill an error if it fails
[14:36] <mandel> sil2100, do you have the rights to trigger a rebuild ps job, one of the tests failed because the machine had a lot of load (http://s-jenkins.ubuntu-ci:8080/job/ubuntu-download-manager-ci/712/rebuild)
[14:37] <mandel> sil2100, this MR - https://code.launchpad.net/~mandel/ubuntu-download-manager/content-disposition/+merge/228804
[14:37] <davmor2> popey: it's black here but I have Saviq silo installed
[14:37] <popey> i dont have any silos, vanila 173
[14:37] <sil2100> mandel: yes, let me try that
[14:37] <mandel> sil2100, awesome, thx
[14:37] <davmor2> Saviq: okay so other than the carousel I don't see anything else that looks broken so far
[14:38] <Saviq> davmor2, ok, I'll find out what's going on there, thanks
[14:38] <sil2100> mandel: ok, retriggered
[14:38] <mandel> sil2100, thx, really appreciate it
[14:40] <davmor2> popey: on flo it looks fine
[14:40] <sil2100> yw :)
[14:41] <plars> brendand: that what failed to run?
[14:42] <Saviq> davmor2, hmm showed up fine here...
[14:42] <Saviq> davmor2, can you try searching for something and clearing the search then?
[14:42] <brendand> plars,  'phablet-config autopilot --dbus-probe enable'. i can see in the console log it did run
[14:42] <plars> brendand: phablet-config autopilot --dbus-probe does run as a setup step for each testsuite, yes
[14:42] <davmor2> Saviq: sure
[14:42] <brendand> plars, but it clearly wasn't succesful, somehow
[14:42] <brendand> plars, i don't have any problem when running locally
[14:42] <bzoltan> sil2100:  I admit everything .. i am a good person to blame for whatever reason :)
[14:42] <plars> brendand: there is a problem with phablet-config that I have an MP for that fixes the fact that it will eat the errors if it fails
[14:43] <plars> brendand: the very next thing we run after phablet-config autopilot runs a script from jdstrand to check that the aa-clickhook stuff was run properly. So if it phablet-config does fail, we should see the effects of it from that
[14:44] <plars> brendand: all the logs I've looked at so far today indicate that it passed though. Are you finding one for certain that failed?
[14:44] <brendand> plars, well the ci failures in 172 are all the same dbus error
[14:44] <brendand> plars, which are identical to the ones you get if you didn't run phablet-config autopilot
[14:46] <plars> brendand: but that's clearly not the problem in this case...
[14:46] <bzoltan> sil2100: popey: let me check if the UITK is the source of that
[14:46] <brendand> plars, well i can't reproduce it locally, so i've nothing else to suspect
[14:46] <plars> brendand: so something else is going on
[14:47] <plars> sergiusens: did you happen to look at my mp for phablet-config?
[14:49] <jdstrand> plars: looking at https://code.launchpad.net/~pwlars/ubuntu-test-cases/touch-add-aa-clickhook-check/+merge/229513, check-clickhook-rules is fine. is the adb-shell command perhaps ignoring an error or not displaying output (like the other issue we saw?)
[14:50] <plars> jdstrand: adb-shell is just a wrapper for adb that lets us actually get the return code from a shell script that runs, and it does not eat output
[14:50] <jdstrand> ok
[14:50] <plars> jdstrand: if we ran adb directly, we wouldn't get the exit code
[14:51] <jdstrand> plars: so, looking at https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/656/consoleText, grep for 'testing ubuntu_clock_app'. you'll see the tests failing due to autopilot down below
[14:51] <plars> jdstrand: right, that's the one I'm looking at right now
[14:52] <sil2100> ogra_: hm, I won't make it for the evening meeting today - could you lead it in my stead? :)
[14:52] <jdstrand> plars: is it possible somewhere between check-clickhook-rules and the first failure that a click is getting installed?
[14:52] <ogra_> sil2100, lol, because its a tricky one ?
[14:53] <ogra_> :)
[14:53] <jdstrand> plars: (the first check-clickhook-rules under 'testing ubuntu_clock_app' that is
[14:53] <jdstrand> )
[14:53] <plars> jdstrand: no, we don't install any clicks, unless the test case itself is doing it
[14:53] <jdstrand> plars: would we see in this output if it is?
[14:55] <plars> jdstrand: I don't know what clock app tests are doing internally, but I seriously doubt they have it installing a click app
[14:55] <sil2100> ogra_: of course!
[14:56] <jdstrand> I'm starting to suspect that while the profiles have the autopilot rule, the cache file may not
[14:57] <jdstrand> plars: I have to step into a meeting, but I'm going to need some more output. I'll give you a script after my meeting. will I be able to run it as root?
[14:58] <plars> jdstrand: certainly. I'm still trying to reproduce this here too
[14:58] <davmor2> popey: your bug about twitter in the indicator, did you notice that the osd notification actually has the avatars in :)
[14:59] <jdstrand> plars: I'm not super confident in the timestamps at this point due to: Aug  5 09:30:46 ubuntu-phablet ntpdate[2552]: step time server <IP_ADDRESS> offset<PHONE_NUMBER>.683614 sec
[14:59] <jdstrand> plars: (timestamps are used when compiling policy so we can use cache files)
[15:00] <jdstrand> plars: my script will attempt to see if that is the issue
[15:00]  * jdstrand -> meeting
[15:00] <boiko> sil2100: is there any thing I need to do on silo 15 now, or is it just a matter of having a core dev to ack the packaging changes now?
[15:01] <t1mp> popey: about the color of the back button, did you notice issues with that in apps as well? or dash only?
[15:02] <popey> t1mp: its fine in dialer, messaging
[15:02] <t1mp> popey: ok, thanks
[15:02] <popey> np
[15:04] <oSoMoN> sil2100, hey, can silo 6 be published, please?
[15:05] <Mirv> oSoMoN: did that for sil
[15:05] <Mirv> while publishing qt declarative as well
[15:05] <oSoMoN> Mirv, awesome, thanks!
[15:09] <oSoMoN> Mirv, sil2100: can I have a silo for line 47, please?
[15:19] <Mirv> oSoMoN: done, but be sure to clean the previous webbrowser app silo as soon as it has migrated
[15:19] <oSoMoN> Mirv, of course, thanks!
[15:21] <popey> sil2100: it's not possible to uninstall apps on 173
[15:21] <popey> davmor2: ^
[15:22] <ogra_> popey, are you sure that wasnt there on 172 ?
[15:22] <ogra_> i mean ... the changeset is three packages for 173 ... (plus language updates)
[15:22] <popey> i dont know
[15:23] <popey> so entirely possible
[15:24] <davmor2> popey, ogra_: I need to reflash to clear out the silos so I'll do 172 and see what happens there
[15:24] <ogra_> davmor2, thanks ... i dont think it can be 173 specific
[15:27] <tvoss> davmor2, ping
[15:29] <davmor2> tvoss: hello
[15:32] <davmor2> ogra_: actually can you give me write access to the silo spreadsheet so I can mark QA approved please or mark line 25 as done thanks :)
[15:32] <ogra_> davi dont know if i can :/ or how i would
[15:33] <ogra_> *davmor2 ^^
[15:33] <davmor2> ogra_: haha no worries definitely a job for sil2100 then
[15:33] <ogra_> i think you need robru for that
[15:33] <ogra_> or sil2100 yeah
[15:35]  * sil2100 does that
[15:35] <sil2100> davmor2: I'll give ya access
[15:35] <sil2100> davmor2: now switch it yourself ;)
[15:36] <davmor2> sil2100: ta
[15:37] <davmor2> oh get you with your fancy granted :)
[15:37] <davmor2> sil2100, Saviq: Done granted :)
[15:39] <Mirv> sil2100: hey MOTU :) could you ack this universe pkg? https://ci-train.ubuntu.com/job/landing-015-2-publish/lastSuccessfulBuild/artifact/packaging_changes_messaging-app_0.1+14.10.20140805-0ubuntu1.diff
[15:40] <Saviq> davmor2, thanks!
[15:40] <Saviq> let's land this!
[15:41] <Saviq> who wants to push the button on silo 7? ;)
[15:41] <Mirv> I can, but it'll need packaging acks
[15:41] <Saviq> Mirv, I can strong-arm mterry to get you those :)
[15:42] <Mirv> Saviq: give him https://ci-train.ubuntu.com/job/landing-007-2-publish/34/artifact/packaging_changes_unity8_8.00+14.10.20140805-0ubuntu1.diff
[15:42] <Saviq> mterry, have a look please ↑?
[15:42]  * mterry looks
[15:43] <sergiusens> slangasek: can you help me out with http://people.canonical.com/~platform/citrain_dashboard/#?q=sergiusens ? preNewing
[15:46] <Mirv> sergiusens: seb promised to try to do that but didn't get to that
[15:46] <mterry> Saviq, Mirv: from a debian-packaging POV, seems fine
[15:47] <sergiusens> Mirv: yeah, that's why I started to roll; not sure who preNew queues work or if archive admins get to notice them
[15:47]  * Mirv should not start straight after vac with days this long
[15:47] <Mirv> mterry: thanks. if you don't mind, there'd be a smaller https://ci-train.ubuntu.com/job/landing-015-2-publish/lastSuccessfulBuild/artifact/packaging_changes_messaging-app_0.1+14.10.20140805-0ubuntu1.diff too
[15:47] <sergiusens> s/who/how/
[15:47] <Mirv> sergiusens: they're completely manual, the admin needs to check the packaging and eg. copyright headers (seemed fine to me)
[15:48] <sergiusens> Mirv: yeah, well rsalveti did review the packaging; but the message says to explicitly wait for an archive admin
[15:48] <sergiusens> :-)
[15:48] <cjwatson> the preNEW thing is kind of unnecessary nonsense for source uploads anyway
[15:48] <cjwatson> they're going to land in actual NEW
[15:49] <cjwatson> it's only new binaries that need prior care because the copy buggily bypasses NEW right now
[15:49] <cjwatson> I think we should stop bothering with preNEW for new sources, and only keep it for new binaries
[15:50] <sergiusens> I'll leave yo your discretion then
[15:50] <sergiusens> or a core devs if it's fine
[15:51] <Mirv> taking a note of what colin says and pushing publish
[15:51] <Mirv> since ricardo reviewed it anyway
[15:53] <mterry> Mirv, for messaging-app...  (A) the new build-dep should be sorted into the list and (B) "cd obj-$(DEB_HOST_GNU_TYPE); ctest -V" should be "cd obj-$(DEB_HOST_GNU_TYPE) && ctest -V" so that we notice when obj-* isn't created where we expect it.  I'm not sure they are stop-the-line problems at this point in the silo process, but I would normally needs-fixing an MP for them
[15:55] <Mirv> mterry: I think sil2100 wants the messaging AP fix in sooner rather than later, but let's get renato___ / boiko to promise they care of those points A and B in the next merge request
[15:55] <camako> kgunn, plz ignore the failure above... It didn't fail.
[15:55] <mterry> Mirv, sure; they aren't showstoppers
[15:55] <kgunn> ack
[15:56] <Mirv> thanks. I'll file a bug against messaging-app
[15:56] <Mirv> renato___ / boiko: filed bug #1352976 for that
[16:08] <elopio> Mirv: I've top-approved the autopilot branch.
[16:09] <Mirv> elopio: thanks. now it'll need a packaging ack still but I'll let someone else handle it or alternatively I'll look pinging some core dev about it in the morning.
[16:10] <elopio> Mirv: I'll ask for a review there. I am eager to get this branch released :)
[16:34] <popey> davmor2: ogra_ uninstalling is broken in 170 too
[16:35]  * popey goes afk for evening merriment
[16:35] <davmor2> popey: can you quickly check if you install an app if it shows in the click store as available still too, that would then confirm my theory of they broke the updater on the scope
[16:35] <popey> ok
[16:36]  * popey installs riddling
[16:36] <popey> shows as installed
[16:36] <popey> in both store and click scope
[16:37] <davmor2> let me try that again then
[16:39] <camako> kgunn, ignore failure msg.. It succeeded. Now starting unity-mir, papi, qtmir...
[16:44] <popey> really afk now
[16:45] <oSoMoN> sil2100, hey, can I have a silo for line 32 please? it’s an oxide landing, no MR associated, need to copy the source package from the phablet-team PPA to the silo, once assigned
[16:47] <oSoMoN> sil2100, I also need silo 8 to be published, when you have a moment. Thanks!
[16:50] <davmor2> popey: from click list net.launchpad.click-webapps.googleplus	6 ,  and in the store http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-08-05-174829.png
[16:50] <davmor2> if I go out of the store and then back in it shows as installed though
[16:56] <robru> oSoMoN, published
[16:56] <oSoMoN> robru, thanks!
[16:56] <robru> oSoMoN, you're welcome!
[16:57] <oSoMoN> robru, have you seen my request a few lines above to get a silo for line 32 for the oxide landing?
[16:57] <robru> oSoMoN, no sorry, just waking up ;-)
[16:58] <oSoMoN> robru, « sil2100, hey, can I have a silo for line 32 please? it’s an oxide landing, no MR associated, need to copy the source package from the phablet-team PPA to the silo, once assigned »
[16:58] <robru> oSoMoN, ok you got silo 6
[16:59] <robru> oSoMoN, oh, did you need *me* to copy the source package?
[16:59] <oSoMoN> robru, yeah, I guess I don’t have permissions to copy to a silo PPA
[17:00] <robru> oSoMoN, you want this package from this ppa? https://launchpad.net/~phablet-team/+archive/ubuntu/ppa
[17:00] <oSoMoN> robru, yep, from this PPA, only the oxide-qt package, not the webbrowser-app one
[17:01] <robru> oSoMoN, ok, submitted the copy, should show up soon
[17:01] <oSoMoN> robru, excellent, thanks!
[17:01] <robru> oSoMoN, you're welcome
[17:02] <pmcgowan> kenvandine, silo 17 has the reset stuff?
[17:03] <oSoMoN> robru, did you do a binary copy? I was told it has to be a source copy, because the phablet-team PPA doesn’t build against utopic-proposed
[17:04] <robru> oh crap
[17:07] <robru> oSoMoN, ugh, ok I need to assign a new silo, 6 is shot
[17:07] <oSoMoN> :/
[17:10] <Wellark> hey, guys. do we need to land this separately or could we just have it as part of silo 1 ?
[17:10] <Wellark> https://code.launchpad.net/~unity-api-team/indicator-network/lp1352744/+merge/229665
[17:10] <Wellark> which is ready to land as soon as people can test it (that bug is causing also the current stuff in silo 1 to fail to start)
[17:13] <robru> Wellark, you're welcome to add that to silo 1, but it looks like somebody tried to publish silo 1 already, so adding that means you have to retest everything else that's already in silo 1
[17:14] <kenvandine> pmcgowan, looks like it... i wasn't quite ready to prepare that, wanted to figure out the CI failures
[17:15] <kenvandine> which are clearly all unrelated to those branches :/
[17:15] <robru> oSoMoN, ok, did a source copy into silo 15
[17:15] <oSoMoN> robru, thanks!
[17:15] <robru> oSoMoN, you're welcome
[17:16] <robru> oSoMoN, dunno, the build job is being weird, anyway you can watch the real builds here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-015/+packages
[17:17] <oSoMoN> robru, yeah, that’s what I usually do
[17:28] <jdstrand> plars: ok, can you insert this after the aa-clickhook run: http://paste.ubuntu.com/7962896/
[17:28] <boiko> Mirv: thanks for the bug report, I'll fix that one
[17:28] <jdstrand> plars: or something similar to it. that is going to be very chatty-- maybe redirect to a file per app? I'll let you decide how to report it
[17:29] <jdstrand> plars: (that needs to be run as root)
[17:30] <Wellark> robru: we now have the fix separately in silo 6
[17:30] <plars> jdstrand: sure, one min
[17:31] <jdstrand> plars: that is only going to be useful on a test run that has the problem unfortunately
[17:32] <jdstrand> plars: you could make the output conditional on if the tests fail. but again, up to you
[17:39] <tvoss> davmor2, ping
[17:57] <davmor2> tvoss: yeap sorry tea got in the way it's installed I just need to get an app on and test it
[17:58] <tvoss> davmor2, browser for the win
[17:59] <davmor2> tvoss: indeed but if it doesn't work with the apps it's pointless ;)
[18:01] <davmor2> tvoss: still having the same issue with location indicator so I don't know if that is going to knock the gps off or not
[18:04] <davmor2> tvoss I have a fix \o/
[18:05] <plars> jdstrand: btw, you've probably already looked at it, but what do you make of the errors in https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/661/artifact/clientlogs/ubuntu_clock_app/application-click-com.ubuntu.clock_clock_1.0.474.log/*view*/
[18:06] <davmor2> tvoss: now the wierd news.  So here maps app, asked twice for location,  Once black and white the old webbrowser request and once in colour with a green comfirm button which I assume is the location service.  However when I opened mpas.google.com I didn't get the second request
[18:06] <plars> ex:
[18:06] <plars> process 3467: arguments to dbus_connection_unref() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file ../../dbus/dbus-connection.c line 2777.
[18:06] <plars> This is normally a bug in some application using the D-Bus library.
[18:06] <davmor2> tvoss: I'm assuming that is because the browser already had permission from here mapps app?
[18:13] <tvoss> davmor2, yup
[18:15] <davmor2> tvoss: I rebooted and tried maps.google.com from the browser again and it again only asked once for permission, trying here maps app again now
[18:17] <tvoss> davmor2, that's actually great, your answer is cached :)
[18:17] <tvoss> davmor2, or better: your previous answer is cached
[18:17] <tvoss> davmor2, so with that: rm -rf ~./local/share/UbuntuLocationService to remove the trust db
[18:20] <tvoss> davmor2, ideally, the first prompt (within the browser) wouldn't look so much like the actual trust prompt
[18:20] <jdstrand> plars: you mean the dconf errors? confined apps aren't allowed to use gsettings
[18:20] <jdstrand> plars: the shm stuff is normal and expected
[18:30] <davmor2> tvoss: I get them in this order http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-08-05-192152.png  and then http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-08-05-192837.png  none of the mapping apps or browser show the second one after it has been selected once.  I'm not sure if that is desired behaviour though, once per app at least I would of assumed
[18:31] <jibel> ToyKeeper, davmor2 could one of you test silo 6
[18:31] <jibel> ?
[18:32] <tvoss> davmor2, can you retry please, with prior removing ~/.local/share/UbuntuLocationService and rebooting?
[18:32] <davmor2> tvoss: that was
[18:33] <tvoss> davmor2, so expected behavior is one actual trust prompt *per* app. So if you open the nokia here app from the store, you should see a trust prompt (colored buttons). If you then go to the browser and open google maps, you should see the trust prompt again
[18:34] <plars> jdstrand: oh, I actually just managed to reproduce this at home!
[18:35] <davmor2> tvoss: I see the http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-08-05-192152.png every time I open anything that needs location as before.  http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-08-05-192837.png  I only saw this once opening here maps from the store
[18:35] <tvoss> davmor2, so the first one comes from the webengine, and thus is the same for webapps and the browser
[18:36] <tvoss> davmor2, the second is issued by the location service
[18:36] <ToyKeeper> jibel: Trying silo 006 now...
[18:36] <davmor2> tvoss: the first is the one I see on every app and browser the second I've only seen once
[18:36] <plars> jdstrand: http://paste.ubuntu.com/7963444/
[18:36] <jibel> ToyKeeper, thank you
[18:36] <jibel> Wellark, ^
[18:37] <tvoss> davmor2, let me quickly retry here
[18:37] <davmor2> ToyKeeper: thanks, I'm looking at 7 currently
[18:37] <tvoss> davmor2, could you make sure that your local nokia here app isn't running unconfined?
[18:38] <davmor2> tvoss: sure how?
[18:41] <Wellark> ToyKeeper: please, ping if you encounter any problems
[18:41] <ToyKeeper> Wellark: So far it looks great...  appears to fix the network indicator issues completely.
[18:41] <Wellark> ToyKeeper: it should :)
[18:42] <Wellark> ToyKeeper: there was an unfortunate non-discovered bug in indicator-network which just happened to surface it self after the last ofono landing
[18:42] <Wellark> we are now updating the test plans to make sure this kind of stuff does not happen in the future
[18:43] <Wellark> Saviq: did you land that dash-as-app silo?
[18:43] <sil2100> o/
[18:43] <Wellark> once silo6 is landed we should try to land silo 1
[18:43] <sil2100> robru, ogra_: so, what's the status? Did you fix everything magically while I was away?
[18:43] <sil2100> robru, ogra_: I don't accept 'no' as an answer
[18:43] <robru> sil2100, oh yep, totally, next image will be 100% green
[18:43] <davmor2> hey sil2100 is that you saying hello or goodbye these waves all look the same to me ;)
[18:44] <ogra_> sil2100, yup, even retroactiverly ... we decided t declare 170 as not broken :P
[18:44] <robru> ogra_, yeah, we promoted that one, didn't we?
[18:44] <sil2100> ogra_: oh, 170 was not b0rken? :O
[18:44] <ogra_> robru, indeed
[18:44] <jdstrand> plars: which app failed?
[18:44]  * sil2100 smells lies
[18:44] <sil2100> ;)
[18:44] <ogra_> haha
[18:45] <Wellark> sil2100, robru, ogra_: silo 1 also fixes the RootState::updateNetworkingIcon() crash in indicator-network that has been bugging us during smoke testing
[18:45] <sil2100> Wellark: \o/
[18:45] <tvoss> davmor2, so working flawlessly here
[18:45] <sil2100> davmor2: hah ;)
[18:45] <ogra_> sil2100, well, nothing new came up in the meeting ... we have to wait for apparmor and the indicator fix .... and then judge the qt4 dropping
[18:45] <tvoss> davmor2, should we jump on a hangout real quick and I show you what I'm doing?
[18:45] <robru> Wellark, right but it needs to be rebuilt after the other conflicting silo lands
[18:45] <plars> jdstrand: I was running clock_app and camera_app tests only after a fresh install
[18:45] <ogra_> the above looks good at least :)
[18:45] <ogra_> one down
[18:45] <plars> jdstrand: they both failed
[18:46] <Wellark> robru: true.
[18:46] <davmor2> tvoss: sure give me 5 minutes
[18:46] <tvoss> davmor2, ack
[18:46] <sil2100> robru: so, anyway, we seem to be 'almost ready' for RTM in CI-Train, I'll just make a few more tests but it's good in overall
[18:47] <robru> sil2100, how is it looking? what changes will I need to make in the dashboard / queuebot?
[18:47] <ogra_> sil2100, so unless apparmor magically fixes itself and qt4 dropping has no side effects at all it smells like traincon-0
[18:47] <sil2100> ogra_: ;/ but did you guys hear any updates on this apparmor situation? Is there at least any lead on what can be the cause?
[18:48] <ogra_> no, but plars and jdstrand are actively working on it
[18:48] <ogra_> (see backlog)
[18:48] <jdstrand> plars: you ran aa-clickhook -f --include=...? and your check-click-hook script returned 0?
[18:49] <sil2100> robru: mostly only cosmetic changes, there will be one additional column needed but in overall most things stay the same
[18:49] <jdstrand> plars: basically, what I am seeing here is that the cache files have a newer timestamp by 44.5 years than the policy files
[18:50] <sil2100> robru: there is some risk involved that when I remove the bazillion workarounds that I had to implement to test this on dogfood it will stop working, but we'll deal with it fast ;)
[18:50] <robru> sil2100, k, when you get a chance can you email me some of the details? I need to know things like a) where will the json files live, b) what's the PPA link, c) jenkins job links, etc, that way I can hook up all the frontend bits
[18:51] <jdstrand> actually, I think I need one more debugging item
[18:51] <sil2100> robru: sure
[18:51] <ToyKeeper> Wellark: The only odd bit I see is that, on one device, the signal bar icon stays visible in flight mode, and on another device that disappears in flight mode.
[18:52] <ogra_> ToyKeeper, did you wait long enough ? the UI updates for that are often really slow
[18:52] <Wellark> ToyKeeper: the panel icons will get a lot of love in silo 1
[18:53] <Wellark> hopefully I get it landed today
[18:53] <ToyKeeper> ogra_: Yes, on one it was almost immediate; the other still hasn't hidden the icon after ~5 minutes.
[18:53] <Wellark> silo 6 just fixes the crash and all of the problems that come with it
[18:53] <jdstrand> plars: I'm really uncomfortable with these timestamps. why is the time so off?
[18:53] <ToyKeeper> Yeah, silo 6 looks awesome.
[18:53] <ogra_> wow, 5 mins is surely not normal
[18:54] <plars> jdstrand: no idea, that's just how it came up
[18:54] <Wellark> ToyKeeper: just wait when you see silo 6 on a dual sim device ;)
[18:54] <ogra_> i have seen the "dripping coffe filter icon" show up for ~1min befor the mobile bars went away
[18:54] <ogra_> but never 5min
[18:54] <ToyKeeper> Wellark: Hmm, will try moving my other sim over to take a look.
[18:54] <Wellark> just need to land silo 6 first
[18:55] <Wellark> otherwise silo 1 keeps crashing just the same
[18:55] <Wellark> ToyKeeper: teaser http://imgur.com/XK0fEWt
[18:55] <ToyKeeper> I got a little distracted by a regression in 173...  looks like the task switcher no longer handles the only-one-app-running case correctly (again).  It doesn't 3D-ify things, so it looks a little confusing.
[18:55] <jdstrand> plars: did you comment on if aa-clickhook --include=... was run successfully and if your check passed?
[18:55] <plars> jdstrand: seems like maybe ntpdateis running at some point after boot
[18:55] <plars> jdstrand: yes, the checks passed fine
[18:56] <plars> jdstrand: but what I'm wondering is if that ran before the ntpdate ran and corrected the time
[18:56] <plars> jdstrand: so what if we came up after install with a *really* old time on the device
[18:56] <jdstrand> plars: if you ran the test again now, does it still fail?
[18:57] <plars> jdstrand: I don't know, probably hit or miss like all the others. I still have the device in the state where the tests left it though in case we need to get anything else off it
[18:58] <plars> jdstrand: so it seems like sometimes right after install, the phone has a datestamp of Jan 12, 1970
[18:58] <jdstrand> plars: right. I have a feeling that is related, since we do all kinds of timestamp checks when loading cache files
[18:58] <nik90> sil2100: we got a bug in image #173 due to the latest ui-toolkit, bug 1353048
[18:58] <Wellark> ToyKeeper: please leave a comment to the MP and state which device you used for testing and what is the test result
[18:58] <Wellark> ToyKeeper: https://code.launchpad.net/~unity-api-team/indicator-network/lp1352744/+merge/229665
[19:02] <ToyKeeper> Wellark: Looks nice, but the SIM card names don't seem to be used in apps other than the settings app.
[19:02] <Wellark> ToyKeeper: that's being worked on
[19:03] <sil2100> nik90: yes, we noticed it earlier, bzoltan1 is aware of it... let me read the backlog
[19:03] <Wellark> ToyKeeper: actually indicator-network won't show up the sim names on devices with silo6 yet
[19:03] <Wellark> that's the next one
[19:03] <Wellark> we just need to get the items in now
[19:03] <Wellark> and then add labels throughout the system
[19:04] <nik90> sil2100: ok
[19:05] <jdstrand> plars: there seems to be data missing from the syslog
[19:06] <jdstrand> plars: ie, I can't see that the clock apparmor profile is loaded into the kernel
[19:07] <jdstrand> plars: can you adjust the infrastructure to run this as early as you can: sysctl -w kernel.printk_ratelimit=0
[19:07] <jdstrand> plars: that will disable kernel rate limiting
[19:08] <jdstrand> plars: that is something we will permanently want in the test infrastructure
[19:08] <jdstrand> sil2100, ogra_: can you point me at the last known good test run?
[19:09] <plars> jdstrand: sure, but couldn't that have a negative effect if we get something spamming?
[19:09] <plars> jdstrand: and which syslog are you looking at? I don't think I sent you one from this run
[19:10] <ogra_> jdstrand, 162 or 165, not sure without looking deeper
[19:12] <jdstrand> plars: I was looking at 656, which was the failed one from ealier
[19:13] <plars> jdstrand: from one of the recent successful runs, I see a bunch of failed ntpdate calls (also seen here) and then: Aug  5 15:00:57 ubuntu-phablet ntpdate[2836]: step time server <IP_ADDRESS> offset 8.587277 sec
[19:13] <jdstrand> plars: it might have a negative side-effect if something spams, but it is known that we can lose valuable information without it. I think it is an appropriate default so disable rate limiting in a testing environment so we don't lose anything
[19:13] <plars> which is way more reasonable
[19:14] <plars> so something is resetting the clock inconsistently
[19:15] <jdstrand> plars: ah yes, that was what I was wondering- if successful ones had good clocks and unsuccessful ones had bad
[19:15] <plars> jdstrand: yep
[19:15] <plars> jdstrand: what's really funny, is that during these two tests I tried locally, they both failed, and I have two entries for: Aug  5 18:35:08 ubuntu-phablet ntpdate[2716]: step time server <IP_ADDRESS> offset<PHONE_NUMBER>.132842 sec
[19:16] <plars> jdstrand: so either the hwclock never got set and it lost it across the reboot before the next test, or something reset it again
[19:18] <jdstrand> plars: I see /etc/init/hwclock-save.conf
[19:18] <tvoss> sil2100, still around?
[19:18] <sil2100> tvoss: yeah, more or less
[19:19] <jdstrand> plars: it should run in runlevel 0 and 6, so a reboot shoud trigger it, if the machine goes down cleanly
[19:19] <plars> root@ubuntu-phablet:~# hwclock
[19:19] <plars> Mon 12 Jan 1970 09:22:57 PM UTC  -1.029365 seconds
[19:19] <tvoss> sil2100, I have to remerge qtmir and qtmir-gles in silo10
[19:19] <tvoss> could use some help with the twins stuff
[19:20] <plars> jdstrand: I think perhaps the reboot bit is calling adb reboot, rather than trying to rely on the OS to reboot
[19:20] <sil2100> tvoss: ok, let me take a look at that silo
[19:20] <jdstrand> plars: I can keep digging to autoritatively determine the series of events that are causing the problem. I feel like we are going to want to have the clock fixed regardless and doing that will resolve this
[19:20] <davmor2> sil2100: https://bugs.launchpad.net/ubuntu/+source/indicator-location/+bug/1352930  jibel did an updated version of the gps indicator
[19:21] <tvoss> sil2100, just pushed the updated gles branch
[19:21] <jdstrand> plars: oh, that would make some sense. you could prior to adb reboot do 'start hwclock-save' and see if that helps
[19:21] <davmor2> sil2100: that's incase it isn't the same issues as it was before
[19:21] <plars> jdstrand: indeed, I think the clock issues have to be the root cause, but why on earth would we need to jump through all these extra hoops for CI? This is something that it seems could potentially hit others
[19:21] <plars> what made us get into this situation where the date is coming up bad
[19:21] <sil2100> tvoss: ok, does the silo need reconfiguration? Or did you only push to already existing branches?
[19:21] <tvoss> sil2100, only to already existing branches
[19:22] <sil2100> davmor2: oh, let me add that to the list, but not a blocker right?
[19:22] <tvoss> sil2100, so we should just need a rebuild for qtmir and qtmir-gles
[19:22] <sil2100> tvoss: ok, doing then :)
[19:23] <jdstrand> plars: yeah, I don't have answers to those questions, except to say that people don't usually adb reboot their device, and if they do, it isn't often, so if this is an intermittent failure that doesn't happen for regular people, maybe they just reboot?
[19:23] <davmor2> sil2100: no just a known issue, that should be monitored closely as currently it might be knocking gps off until tvoss's location service lands fingers crossed for latter tonight or tomorrow am
[19:23] <jdstrand> s/happen/happen often/
[19:23] <plars> jdstrand: no, more likely they don't reboot it at all unless they hard-power it off
[19:24] <plars> ogra_: any ideas on the clock?^
[19:24] <jdstrand> right, I would think that would still not save the hwclock
[19:24] <jdstrand> but maybe we run some stuff on power button press
[19:24] <plars> jdstrand: I'm not opposed to working around this if we really have to, but I think we should understand how we got here and ensure we're not just hiding the bug from ourselves in the future.
[19:25] <jdstrand> plars: yes, I agree
[19:25] <jdstrand> that is a good point
[19:25] <plars> we've been asked to do things like that before, and resisted, and learned that it was a real bug after all :)
[19:27] <jdstrand> sure, that makes sense
[19:27] <plars> jdstrand: but I wouldn't think it's apparmor's fault either here. But it makes me wonder if my thinking is backwards.... if we push those aa-clickhook changes when the date is set to 1970, and then the date gets updated, wouldn't apparmor have even more urgency to update what it has cached?
[19:31] <jdstrand> plars: well, that is the thing-- I don't have enough data to say what is exactly happening
[19:31] <jdstrand> plars: I need the sysctl in place to do that
[19:31] <jdstrand> I can say that the cache files are newer than the policy files by 44 years
[19:31] <Wellark> can we now land silo 6 as ToyKeeper has tested on relevant devices?
[19:32] <Wellark> I will try to get tedg to set the silo as "Testing done"
[19:32] <ToyKeeper> Wellark: That happened about 23 minutes ago.
[19:32] <plars> jdstrand: where can I find the cache files? I still have that system booted at my desk right now
[19:32] <Wellark> ToyKeeper: I didn't get the memo..
[19:32] <Wellark> ;)
[19:32] <Wellark> ok. great
[19:32] <Wellark> thanks!
[19:32] <jdstrand> plars: /var/cache/apparmor
[19:33] <ToyKeeper> Wellark: Do you get notices from queuebot?
[19:33] <jdstrand> plars: I think I see the issue
[19:33] <jdstrand> elif os.lstat(hook_full).st_mtime > os.stat(profile).st_mtime:
[19:33] <jdstrand> # If the profile exists, but the hook symlink is newer, we need to
[19:33] <jdstrand> # regenerate it. Click may update the symlink from time to time, so
[19:33] <jdstrand> # we need to handle this (LP: #1291549)
[19:33] <jdstrand> ...
[19:33] <ToyKeeper> Wellark: The last silo 6 notice I saw was: -queuebot/#ubuntu-ci-eng- Silos: landing-006 (pete-woods, Wellark) Migration: One package at least is not available at the destination. indicator-network (0.5.1+14.10.20140805-0ubuntu1) is in the proposed pocket.  (indicator-network)
[19:33] <jdstrand> meh bug bot
[19:33] <jdstrand> plars: notice, that check is '>'
[19:33] <nik90> hey guys what's up with all the clock app tests failing in the dashboard?
[19:33] <jdstrand> plars: the timestamps are all the same
[19:34] <nik90> I haven't made any change to the AP tests for sometime now
[19:34] <jdstrand> (1970)
[19:34] <jdstrand> well, but the profile has the code, so that isn't it
[19:34] <Wellark> robru: plz help to debug silo 6
[19:34] <jdstrand> yeah, I need more data
[19:34] <robru> Wellark, what's wrong with silo 6?
[19:35] <Wellark> robru: the status is weird
[19:35] <Wellark> In silo landing-006. Migration: One package at least is not available at the destination. indicator-network (0.5.1+14.10.20140805-0ubuntu1) is in the proposed pocket.
[19:35] <jdstrand> plars: I need to know when the clock app profile was loaded so I can compare it to the timestamps in the paste you gave me
[19:35] <robru> Wellark, yes... that is completely unremarkable.
[19:35] <tvoss> davmor2, found the issue
[19:36] <davmor2> tvoss: \o/
[19:37] <tvoss> sil2100, so once the packages are built, we have to adjust the changelog entry in the gles-branch, correct?
[19:37] <Wellark> robru: ok. silo 1 needs a rebuild.
[19:37] <Wellark> robru: oh, wait.. I need to update the unity8 dependency version
[19:37] <robru> Wellark, don't rebuild silo 1 until after 6 is merged.
[19:38]  * Wellark wonders what is the latest version of unity8
[19:38] <Wellark> queuebot: where unity8
[19:38] <Wellark> ;(
[19:39] <jdstrand> plars: ok, I think I have it. we precompile apparmor policy for clicks shipped on the device. those have a timestamp of today. with aa-clickhook is run, the policy is regenerated, but the clock is still at 1970. when the parser goes to load the policy, it sees the cache files from 2014 and the policy with a timestamp of 1970 and so it skips them
[19:40] <plars> jdstrand: ah, that makes some sense
[19:40] <plars> jdstrand: so we are actually pushing what it believes to be an older policy
[19:40] <plars> jdstrand: that sounds plausible
[19:40] <jdstrand> ok, I've definitely convinced myself that we need to fix the clock :)
[19:40] <plars> :)
[19:40] <plars> ogra_, sil2100: any ideas how we are timetraveling?
[19:41] <plars> ogra_, sil2100: it looks like we've created a paradox in the universe, and apparmor is trying to prevent a temporal rift from killing us all. Thanks to jdstrand and his excellent code that prevents the universe from being torn asunder
[19:42] <jdstrand> heh
[19:43] <sil2100> :O
[19:43] <kgunn> robru: hey there, is there a way you could move the mir stuff to a new silo, we've been dorking around with symbol stuff...we're thinking 2 of the rdeps we're trying to build are getting hung up on some residue
[19:43] <sil2100> wow
[19:44] <plars> with all the systemd related problems, I blame that. And it got update in 164 right before we started hitting this :)
[19:44] <robru> kgunn, you mean silo 9? yeah I can do that
[19:44] <sil2100> plars, jdstrand: ok guys, this sounds like a really crazy bug
[19:45] <plars> sil2100: nah, I just made it sound much more serious in hopes someone would fix it :)
[19:45] <jdstrand> its actually probably a simple bug, it was just hard to triage
[19:45] <jdstrand> well, triage to the point were someone can really now dig in
[19:45] <robru> cjwatson, infinity, stgraber: anybody around to ack a new binary package? https://ci-train.ubuntu.com/job/landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_address-book-service_0.1.1+14.10.20140804-0ubuntu1.diff
[19:45] <sil2100> Indeed, as no one would suspect the timing of the clickhook to being a bit unfortunate
[19:46] <plars> but apparmor is doing the right thing - it's not updating to the "new" profile from 1970
[19:46] <Saviq> Wellark, fwiw, your unity8 branch in silo 1 isn't reviewed yet
[19:46] <jdstrand> it would've been ok if we didn't precompile policy
[19:46] <Saviq> Wellark, so it will only land tomorrow at the earliest
[19:46] <jdstrand> for some definition of 'ok'
[19:46] <jdstrand> the clock would still be off and who knows what other issues that might cause
[19:47] <jdstrand> sil2100: yeah, as plars said, it isn't click-apparmor or apparmor's fault. we need to have a clock that is not 44 years off :P
[19:48] <jdstrand> for today, we needed it to be less than a few hours off
[19:48] <davmor2> sil2100: did you answer tvoss?
[19:48] <jdstrand> (since each new image recompiles the cache files for pre-caching)
[19:48] <jdstrand> s/new image/new image generation/
[19:49] <Wellark> Saviq: i thought dednick reviewed it already, but OK.
[19:49] <Saviq> Wellark, I asked him today and he said he didn't test it yet, will make sure this happens tomorrow
[19:50] <robru> kgunn, you're in 7 now
[19:51] <sil2100> tvoss: ah, yes, sorry, missed that - we need to make sure the versions are the same
[19:51] <davmor2> plars: that or jdstrand is actually the Doctor
[19:51] <plars> davmor2: no, then the clock would be off by the *other* direction
[19:52] <plars> which would actually be ok for this
[19:53] <davmor2> plars: no he can go anywhere in time, it's a big squirmy wormy, timey whimy thing it's hard to explain ;)
[19:55] <tvoss> sil2100, do we have a version, yet?
[19:55] <sil2100> tvoss: yeah, let me get it (still building though)
[19:56] <sil2100> tvoss: 0.4.0+14.10.20140805.1-0ubuntu1
[19:59] <tvoss> sil2100, pushed
[19:59] <sil2100> tvoss: excellent
[20:04] <plars> jdstrand, sil2100: interesting, here's a line from syslog during boot in a good run. vs a bad run respectively:
[20:04] <plars> Jul 31 23:50:51 ubuntu-phablet kernel: [    2.315092] rtc-pm8xxx rtc-pm8xxx: setting system clock to 2014-07-31 23:50:47 UTC<PHONE_NUMBER>)
[20:04] <plars> [    2.191240] rtc-pm8xxx rtc-pm8xxx: setting system clock to 1970-01-12 20:38:34 UTC (1024714)
[20:05] <plars> nm, I guess that's just confirming what we already suspected, that the hwclock is wrong on boot in some cases
[20:09] <Saviq> robru, hey, we're down to 1 utopic&&amd64 vm on s-jenkins, do you know if anything can be done about that?
[20:10] <Saviq> this one seems to be stuck launching http://s-jenkins.ubuntu-ci:8080/computer/ps-utopic-server-amd64-1/? :|
[20:11] <Saviq> camako, FYI, unity-mir is deprecated, probably doesn't make sense to update it any more
[20:11] <Saviq> we should be cleaning it up from distro
[20:16] <robru> Saviq, nope, try Ursinha for that one
[20:16] <Ursinha> moi?
[20:16] <Saviq> oui
[20:16] <Ursinha> :)
[20:16] <robru> Ursinha, vanguard ;-)
[20:16] <Saviq>  we're down to 1 utopic&&amd64 vm on s-jenkins, do you know if anything can be done about that?
[20:16] <Saviq>  this one seems to be stuck launching http://s-jenkins.ubuntu-ci:8080/computer/ps-utopic-server-amd64-1/? :|
[20:16] <Saviq> Ursinha, ↑
[20:16] <Ursinha> ah, I'm not vanguard anymore, but I can have a look :)
[20:17] <Ursinha> Saviq: let me see
[20:17] <Saviq> Ursinha, /topic says you are ;)
[20:17] <Saviq> robru, ah, sorry, misread the "Train" in /topic
[20:17] <Ursinha> Saviq: yeah, I forgot changing that :) it's my fault, I'll reply the request :P
[20:18] <robru> Saviq, no worries. I'm vanguard sometimes, but I don't actually know about this request ;-)
[20:19] <robru> Wellark, ok, merged 6 and rebuilding 1.
[20:22] <Wellark> robru: thanks!
[20:23] <robru> Wellark, you're welcome!
[20:24] <rsalveti> robru: mind reconfiguring silo 3?
[20:25] <robru> rsalveti, can do
[20:25] <robru> rsalveti, well there's a build job running by jhodapp, is that on purpose?
[20:25] <jhodapp> yes
[20:26] <jhodapp> if it needs a reconfigure you can kill the build
[20:28] <rsalveti> jhodapp: robru: sorry, we can reconfigure after the build
[20:28] <rsalveti> no worries
[20:29] <rsalveti> just added 2 extra src packages to the silo
[20:29] <jhodapp> ok cool
[20:29] <robru> rsalveti, ah ok, yeah if there's no changes toe xisting source packages, lets let those build then reconfigure after. just ping me when the build is done
[20:29] <rsalveti> sure, thanks
[20:33] <tedg> robru, Can I get a silo for Line 30 please?
[20:34] <robru> tedg, ok you gto #6
[20:34] <tedg> robru, Great, thanks!
[20:34] <robru> tedg, you're welcome!
[20:45] <jhodapp> robru, we need a reconfigure on silo 3 after all
[20:46] <robru> ah, manual upload. ok
[20:48] <rsalveti> great, just missing android now
[20:48] <rsalveti> testing on every device now
[20:50] <rsalveti> ogra_mobile: on krillin? :-)
[20:54] <rsalveti> jhodapp: for some reason my videos didn't pick my recorded video
[20:54] <rsalveti> the scopes
[20:55] <jhodapp> rsalveti, yeah I think it might be the scopes...because gallery app pics up the video
[20:55] <jhodapp> rsalveti, but not entirely sure...if you close the camera-app the scopes pick up the new video
[20:55] <davmor2> rsalveti: check the permissions and then on the video scope do a search
[20:56] <nik90> rsalveti, jhodapp: I saw my recorded video in the video scope. however on clicking it to play open the mediaplayer app, but the apps shows an error dialog that no video was selected to play it
[20:56] <rsalveti> yeah, worked fine from file manager
[20:56] <davmor2> it might just be that the scope needs to be triggered to search again
[20:56] <jhodapp> nik90, I've seen that too
[20:56] <rsalveti> permission is fine
[20:56] <rsalveti> lol, yeah
[20:56] <rsalveti> it works as soon I hit search
[20:56] <jhodapp> scope bug then I guess
[20:57] <davmor2> rsalveti, jhodapp: Media scanner scope bug it does a search initially on boot I don't know when it is triggered to look for videos after that
[20:57] <rsalveti> right
[20:58] <jhodapp> davmor2, it should be triggered to monitor the directory for filesystem event changes
[20:59] <davmor2> jhodapp: but then when does the scope know to update, does media scanner say I have a new file show it?
[20:59] <jhodapp> davmor2, that I don't know how it works
[21:00] <jhodapp> davmor2, there should be some trigger because when you copy videos over with MTP, the scopes update
[21:00] <davmor2> jhodapp: but only when there are no videos on the device I think I could be wrong though
[21:00] <jhodapp> davmor2, I'm pretty sure all of the time
[21:01] <davmor2> jhodapp: ah fair enough
[21:01] <jhodapp> davmor2, unless that's changed recently
[21:01] <jhodapp> davmor2, only one way to find out :)
[21:01] <davmor2> anyway way passed my EOD night all
[21:01] <jhodapp> later davmor2
[21:03] <rsalveti> we should probably kick an image soon
[21:03] <rsalveti> quite many changes
[21:03] <rsalveti> robru: is that planned?
[21:04] <ogra_mobile> rsalveti, shhhh !
[21:05] <rsalveti> ogra_mobile: what, talking about dragon ball
[21:05] <ogra_mobile> lol
[21:07] <rsalveti> robru: ogra_mobile: will trigger a new build in ~23 min if that is fine
[21:10] <ogra_mobile> sure, go ahead
[21:11] <rsalveti> great
[21:21] <jhodapp> rsalveti, building qtubuntu-camera for silo 3
[21:24] <veebers> robru, thomi: when you have a moment I have a query re: changes in archive vs what's in trunk and release
[21:28] <tvoss> davmor2, in case you are *still* around: silo 10 is good to go
[21:29] <slangasek> sergiusens: sorry, I was just EOD here at the sprint when you pinged me - does http://people.canonical.com/~platform/citrain_dashboard/#?q=sergiusens still need a look?
[21:31] <Saviq> robru, can we have a reconf on silo 7 please? added qtmir-gles there
[21:31] <robru> veebers, Saviq: sorry in meeting, one sec
[21:31] <Saviq> nw
[21:31] <veebers> robru: nw, I knew that :-)
[21:32] <veebers> robru: I'm not sure what to do with this changeset as it seems to be applied against the lp:autopilot/1.5 release branch but not lp:trunk (http://launchpadlibrarian.net/181532211/autopilot_1.5.0%2B14.10.20140716-0ubuntu1_1.5.0%2B14.10.20140716-0ubuntu2.diff.gz)
[21:32] <robru> slangasek, you here?? ;-) ^^
[21:32] <veebers> robru: so, I can merge it into 1.5 ok, but then it won't exist in the trunk codebase, will that cause an issue?
[21:33] <slangasek> veebers: merge it both places, please :)
[21:33] <slangasek> I can raise an MP if needed
[21:33] <robru> veebers, well, it's not really applied against 'trunk' or 'the 1.5 branch', it's applied against what's in distro.
[21:34] <robru> veebers, yeah, so syncing it everywhere is ideal
[21:34] <Ursinha> Saviq: other two utopic amd64 nodes might be corrupted, we're looking into it
[21:34] <Saviq> Ursinha, ok thanks
[21:34] <veebers> robru: ack, that makes sense thanks. I hope I can do it it in a way that doesn't cause conflicts :-)
[21:34] <slangasek> veebers: it would be awfully lovely from my POV if there were not two branches to merge to in the first place
[21:34] <Saviq> slangasek, as you're around, can you tell me what the process is for dropping a package from archives (unity-mir)?
[21:34] <slangasek> veebers: and certainly I do not expect you to have any difficulty with merge conflicts
[21:34] <slangasek> Saviq: source package?
[21:35] <robru> Saviq, reconfiguring 7
[21:35] <Saviq> slangasek, unity-mir, yup
[21:35] <Saviq> robru, yes please
[21:35] <Saviq> slangasek, got replaced by qtmir already
[21:35] <robru> rsalveti, oops, was in meeting. image build fine by me
[21:35] <robru> rsalveti, want me to do it?
[21:35] <rsalveti> robru: great, that would be awesome
[21:35] <robru> Saviq, i meant, it's happening ;-)
[21:35] <robru> rsalveti, ok. right now?
[21:36] <slangasek> Saviq: file a bug against the package; subscribe ~ubuntu-archiev
[21:36] <rsalveti> robru: yeah
[21:36] <slangasek> Saviq: file a bug against the package; subscribe ~ubuntu-archive
[21:36] <robru> rsalveti, ok, on it
[21:36] <veebers> slangasek: ack
[21:36] <Saviq> robru, ah, 7 looked like ? ;)
[21:37] <Saviq> slangasek, will do, thanks
[21:37] <robru> Saviq, hehe
[21:38] <robru> slangasek, oh, can you ack a new binary package? I know you are just relaxing with tons of free time right now ;-) https://ci-train.ubuntu.com/job/landing-014-2-publish/62/artifact/packaging_changes_address-book-service_0.1.1+14.10.20140804-0ubuntu1.diff
[21:38] <slangasek> robru: currently reviewing ciborium
[21:38] <slangasek> loving the naming schemes, btw :)
[21:39] <rsalveti> robru: thanks
[21:40] <robru> rsalveti, you're welcome
[21:40] <slangasek> sergiusens: oh, but I am reminded that new source packages don't need to be pre-reviewed
[21:40] <slangasek> sergiusens: so please feel free to publish this in the normal way and I'll pick it up from there
[21:41] <cjwatson> I thought somebody already had
[21:41] <sergiusens> slangasek: it's been published by Mirv; just sitting in the queue now
[21:41] <slangasek> sergiusens: ok, so not pre-review at all
[21:41] <sergiusens> I'm just waiting for that to happen eventually
[21:41] <cjwatson> right, it's simply review :)
[21:42] <sergiusens> was just asking about preNew since there isn't much info around that
[21:42] <sergiusens> that I found at least
[21:44] <slangasek> sergiusens: you set DEB_HOST_ARCH but don't use it; and I think you could quite reasonably leave this in /usr/bin instead of moving it into a private dir
[21:44] <slangasek> and accepted
[21:45] <imgbot> [21:45] <sergiusens> slangasek: I can change that; was just applying the trend I was seeing recently in some packages
[21:45] <veebers> slangasek: to clarify, how come these changes (packaging changes to autopilot) weren't done through an MP + silo etc. ?
[21:45]  * sergiusens takes note of adjustments
[21:45] <slangasek> sergiusens: there's no reason you *need* to hide this in /usr/lib, and doing so seems to make debian/rules a lot more complicated than it should be
[21:46] <sergiusens> that is true
[21:48] <slangasek> om26er, robru: address-book-service - what's the reason of adding the test as a new binary package?
[21:49] <robru> slangasek, dunno. renato___ boiko ^^ ?
[21:50] <om26er> slangasek, we install a python fixture with that, that can be used by external applications like messaging-app dialer and address-book for testing
[21:51] <om26er> well the new fixture is part of the address-book-service testcode now.
[21:51] <slangasek> hmm, I have no idea what a "fixture" is
[21:52] <slangasek> but at least "it's used by other packages" explains
[21:53] <om26er> slangasek, its a reusable helper class, that in this case, helps add fake contact in the service for testing purpose.
[21:55] <slangasek> robru, om26er: ok, approved
[21:57] <davmor3> tvoss, sil2100, robru: silo10 is good to go be nice to get that in for the morning image
[21:57] <pmcgowan> slangasek, where do I find the crash reports for say system settings?
[21:58] <slangasek> pmcgowan: https://errors.ubuntu.com/?package=ubuntu-system-settings&period=day
[21:58] <pmcgowan> slangasek, thank you
[21:59] <robru> davmor8, ok, can publish once it's done building
[22:00] <davmor3> robru: Thanks dude :)
[22:00] <davmor3> Right back to bed
[22:04] <Saviq> robru, reconf on silo 1 please, added unity-scopes-shell (and a slew of unity8 MPs, basically took over thostr's silo :P)
[22:05] <robru> Saviq, ok going... did you say you merged a silo? is there another silo I can clear because of this?
[22:05] <Saviq> robru, no, I took it over
[22:05] <robru> Saviq, oh ok
[22:06] <Saviq> there were just 2 MPs before, more like 20 now ;)
[22:06] <Saviq> and there's plenty more when those came from...
[22:08] <pmcgowan> slangasek, once I trigger a crash it should automatically get uploaded now yes?
[22:08] <pmcgowan> ah I see the magic hapen
[22:09] <slangasek> pmcgowan: this is true for a newly-installed device.  If you've been upgrading continuously, you need to manually toggle a setting in system-settings
[22:10] <pmcgowan> slangasek, ok, now any way to identify the crash I just triggered on errors page?
[22:11] <slangasek> pmcgowan: hum - in theory yes but I don't know how to extract this from the phone
[22:12] <slangasek> jibel: you had a way to get the whoopsie identifier off of a device, right?  (Even though it doesn't work reliably)
[22:12] <ogra_mobile> you need the whoopsie id
[22:13] <pmcgowan> ogra_mobile, wheres that
[22:14] <ogra_mobile> should be in the url that opens when you click "previous error reports"
[22:14] <ogra_mobile> on the privacy settings
[22:17] <pmcgowan> ogra_mobile, nothing there
[22:18] <pmcgowan> I didnt see any new reports either
[22:19] <veebers> robru: any idea why the build job was unable to create a changelog from the unmerged revisions in the MP for the silo? (https://ci-train.ubuntu.com/job/landing-004-1-build/158/console)
[22:20] <robru> veebers, oh, yeah, that's because you merged steve's change which touched debian/changelog and then didn't actually add a new debian/changelog entry with your new changes.
[22:20] <robru> veebers, generally the best way to avoid this is to just merge those kinds of changes directly in trunk, not into the silo build
[22:21] <robru> veebers, but since we're in this situation now, you have to add a new entry in debian/changelog
[22:21] <veebers> robru: right, so I'm just going through now cerating one based on the unmerged
[22:21] <veebers> robru: ack, so I shouldn't have merged into lp:ap/1.5 just lp:ap. I'll keep that in mind, cheers
[22:21] <ogra_> pmcgowan, no, it is broken, but your whoopsie ID is your user ID in the URL in the browser now
[22:22] <veebers> robru. slangasek: how come those packaging changes were pushed directly and not through a MP + silo?
[22:22] <robru> veebers, because core devs just do that sometimes? I dunno, that was the official way of doing things since long before citrain ever existed.
[22:23] <pmcgowan> ogra_, that enormous guid string?
[22:23] <ogra_> yep
[22:23] <ogra_> pmcgowan, there is also a dbus way i think ... ask ev
[22:24] <veebers> robru: hmm, ok cheers.
[22:24] <robru> veebers, so just add a new stanza at the top of debian/changelog that says 'UNRELEASED' where the other stanzas say 'utopic' and it should work.
[22:25] <slangasek> veebers: because when I asked thomi earlier same day about a silo for autopilot-qt, I was told that this was currently untestable through a silo so I should feel free to push my packaging-only changes direct
[22:25] <ev> ogra_, pmcgowan, slangasek: sudo gdbus call -y -d com.ubuntu.WhoopsiePreferences -o /com/ubuntu/WhoopsiePreferences -m com.ubuntu.WhoopsiePreferences.GetIdentifier
[22:25] <veebers> robru: ok, do I need to increase the version number? or use dch to do so?
[22:25] <robru> veebers, yeah, sorry, earlier when you asked about this I didn't realize that you were merging 1.5 into trunk, I thought they were two diverged branches. if I'd realized, I would have just said "yeah push steve's thing to trunk only"
[22:25] <veebers> slangasek: ack, thanks makes sense :-)
[22:26] <veebers> robru: no worries, I had a couple of people give me options on how to proceed and picked that one. It's good practice for next time :-)
[22:27] <pmcgowan> ev, thanks now how do I use that to find the report on errors.u.c :
[22:27] <pmcgowan> ?
[22:27] <ev> pmcgowan: tack that on the end of https://errors.ubuntu.com/user/
[22:28] <veebers> robru: can you confirm my Q about version number?
[22:28]  * ev -> bed
[22:28] <robru> veebers, yeah you need to bump it, I'm just checking dch options for you because dch never really does what I expect it to
[22:28] <veebers> robru: heh, sweet I think -i or -a. I'll have a go at it
[22:29] <pmcgowan> ev, ok but nothing there, is there a delay after an upload?
[22:29] <ev> pmcgowan: check to make sure you have a .uploaded file in /var/crash
[22:29] <Ursinha> Saviq: your nodes should be back online
[22:29] <robru> veebers, yeah, neither -i nor -a did it, you need to make a whole new entry, not just adding a bullet point at the end of the current entry.
[22:29] <pmcgowan> ev, I do indeed
[22:29] <Saviq> Ursinha, thank you plenty
[22:29] <veebers> robru: oh *blush*
[22:30] <ev> pmcgowan: quite perplexing. Does syslog give you any output from whoopsie? Could you pastebin it?
[22:30] <veebers> robru: -i seems to do that for me (new line with *-ubuntu3 UNRELEASED etc)
[22:30] <pmcgowan> ev, anything I can grep on?
[22:31] <ev> whoopsie :)
[22:31] <pmcgowan> yeah nothin
[22:31] <ev> and `sudo status whoopsie` shows it running?
[22:31] <pmcgowan> ev yes
[22:31] <robru> veebers, yeah I dunno, when I try 'dch -i' here locally it just clobbers over the existing most recent entry in debian/changelog. Yeah it gives a new version, but it just clobbers the existing most recent version
[22:32] <pmcgowan> ev it made an uploaded file right after I triggered the crash
[22:32] <ev> pmcgowan: is there a /var/log/upstart/whoopsie.log?
[22:33] <robru> veebers, alternately you could just revert the debian/changelog changes in the 1.5 branch and then citrain can generate the changelog for you as it always does
[22:33] <pmcgowan> ev, yep, looks good http://pastebin.ubuntu.com/7965105/
[22:33] <pmcgowan> and I can get the whoops id there so I could find my report with that I suppose
[22:34] <ev> pmcgowan: does your /var/crash/*.crash file have a SystemIdentifier field?
[22:34] <ev> oh wait, it wouldn't
[22:35] <ev> hmmm
[22:35] <pmcgowan> ev, nope
[22:35] <ev> pmcgowan: can you PM me the output of that dbus command?
[22:39] <veebers> robru: fyi this is what I came up with: https://code.launchpad.net/~veebers/autopilot/release-changelog/+merge/229704
[22:39] <ev> pmcgowan: did you reboot since this crash occurred?
[22:39] <pmcgowan> ev, no
[22:40] <pmcgowan> ev, maybe I ran the gdbus thing wrong, I did adb shell which may not be root anymore
[22:41] <pmcgowan> no same
[22:42] <ev> yeah, that is very strange
[22:42] <ev> is it changing on subsequent runs?
[22:42] <ev> the gdbus command, that is
[22:42] <ev> (whatever you do, don't paste the system identifier in public)
[22:43] <robru> veebers, that'll work, but version number 20140805-0ubuntu1 would be better. 0ubuntu3 implies that it's a tiny patch, not a major upstream release.
[22:43] <veebers> robru: oh ok, good catch. I just used dch :-)
[22:44] <veebers> I can change the the version number manually now
[22:44] <robru> veebers, yeah, dch, never works ;-)
[22:45] <veebers> robru: how pedantic are we, over in NZ it's actually 20140806 :-)
[22:45] <robru> veebers, that's fine
[22:45] <robru> crazy time travellers
[22:45] <robru> ;-)
[22:45] <veebers> robru: ^_^ Thanks again for all the help this morn
[22:46] <robru> veebers, no worries
[22:49] <veebers> robru: I've updated the version number as per your comment
[22:50] <robru> veebers, thanks
[22:56] <slangasek> psivaa: are you able to log in to the system exhibiting http://ci.ubuntu.com/smokeng/utopic/touch/mako/172:20140805.1:20140728.1/9490/default/1486871/ ? Would like to know if /var/lib/apport/autoreport exists
[23:15] <plars> slangasek: since we use phablet-config to skip the wizard, I had to make our scripts create /var/lib/apport/autoreport. You can see where the command ran at http://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/658/consoleFull
[23:15] <plars> slangasek: that phone has run other jobs since then, but I'm certain the autoreport file is there
[23:19] <slangasek> plars: the file is not created by the wizard; it's present in any fresh install
[23:20] <imgbot> [23:20] <imgbot> [23:20] <plars> slangasek: oh is that new? not too long ago I discovered it isn't created if you skip the wizard
[23:20] <slangasek> plars: creating the file from your scripts would explicitly undermine the purpose of this test, which is to ensure that autosubmission works without modification :)
[23:20] <plars> slangasek: apparently the wizard is supposed to ask if you want the reports sent
[23:21] <slangasek> plars: the wizard doesn't ask - it's not created even if you do go through the wizard
[23:21] <slangasek> the wizard lets you know it will be autosubmitted (which was a lie until a couple of days ago)
[23:21] <plars> slangasek: from talking to bdmurray, my understanding was that if that file doesn't exist, we don't get submissions.  We can have it *not* create that file if you prefer though
[23:22] <slangasek> plars: yes, your scripts should not be modifying the environment to create that file
[23:22] <slangasek> it was a critical bug that the file wasn't being created
[23:22] <plars> slangasek: well, at one point we were told they should be
[23:22] <plars> so I'll change it back then
[23:22] <slangasek> ok - at this point, you definitely shouldnt
[23:26] <plars> slangasek: Just pushed the change, but I missed the cut for 174 to start testing by 1 or 2 minutes
[23:26] <slangasek> ok
[23:26] <plars> so the results for 174 will have still created it
[23:27] <slangasek> plars: at any rate, you creating the file manually should have let the test *pass* even if the install was broken, so I still don't know what's going on to cause the failure
[23:27] <slangasek> I thought I was all clever in instrumenting the different phases of the process with debugging output, but I still manage to get it into a state with confusing failures
[23:29] <plars> slangasek: well, we are getting some strangeness that jdstrand and I were investigating earlier. For some reason the phones sometimes come up thinking it's January 12, 1970, and it takes a bit for ntpdate to sync up
[23:29] <plars> slangasek: possible that's confusing whoopsie too? It's doing bad things when we try to setup the apparmor profiles
[23:31] <slangasek> I don't see how that would confuse whoopsie_upload_all, but I don't know
[23:34] <robru> kgunn, you got silo 2 but just note it conflicts with 7