[01:34] <robru> back
[01:47] <thomi> doanac: you around?
[01:51] <thomi> cihelp - is mako-07 down? The autopilot release gatekeeper job is stuck
[01:53] <fginther> thomi, the jenkins slave process was dead, I've restarted it
[01:54] <thomi> fginther: thanks
[01:54]  * thomi tries again
[01:54] <thomi> that looks better, thanks fginther
[01:55] <fginther> thomi, no problem, glad it's working again
[02:09] <imgbot> [02:15] <plars> fginther: speaking of that job... a couple of things I wanted to ask you about with it
[02:15] <plars> err
[02:15] <plars> sorry fginther, I meant to say thomi :)
[02:15] <thomi> plars: shoot
[02:16] <plars> thomi: on that gatekeeper job, Saviq was asking earlier if we could make the channel selectable, and default to utopic
[02:16] <plars> thomi: I was going to just change it, but wanted to talk to you first
[02:16] <thomi> plars: it's not utopic already?
[02:17] <thomi> heh.. yeah, let's change that pleae :)
[02:17] <plars> thomi: nope, it's on trusty still
[02:17] <thomi> hmm, I guess I assumed it ran whatever smoketests ran
[02:17] <plars> thomi: the other thing was what you and I and doanac had talked about before - removing the selection of mako-07 specifically and have it just use the daily-mako pool
[02:17] <plars> thomi: we're parallelizing those jobs now, so there's less risk
[02:17] <thomi> plars: that sounds great as well
[02:18] <plars> thomi: and also I already sorta offered up mako-07 up as a sacrifice (to be replaced later)
[02:18] <thomi> plars: How confident should I be that the job does the same thing as the smoke runner job?
[02:18] <plars> thomi: but sometime soon it's going to get pulled out and we're going to do surgery on it
[02:18] <thomi> plars: ok, well, I cancelled the job, so it's not doing anything right now
[02:18] <thomi> we need to land a new branch and then try again
[02:19] <thomi> so I guess it'll be free for a few hours at least
[02:19] <plars> thomi: oh the job won't change at all for this part, I'm just going to change it so that instead of telling it to run on mako-07, it runs on $some_mako from a pool
[02:19] <thomi> ok
[02:19] <plars> thomi: do you generate that job from a script, or was it manually configured?
[02:20] <thomi> plars: doanac made the job for us, I have no idea how
[02:20] <thomi> I'm just concerned that the smoke test job may have changed, and we'd like those changes to apply to our job as well
[02:20] <thomi> so we're testing the same as the smoke test job
[02:21] <plars> thomi: heh, someone already added a $series with "#TODO support $series"
[02:21] <thomi> heh
[02:21] <plars> thomi: but I'm going to just add a $channel since I'm not sure if that's used somewhere else
[02:21] <plars> we can remove it later if possible
[02:21] <plars> since I'd like to just specify the full channel
[02:22] <plars> ex. ubuntu-touch/utopic-proposed
[02:22] <thomi> ok
[02:22] <thomi> so, when I re-run that job, it should pick up the right channel now?
[02:25] <plars> thomi: yes, I just made the changes. Is it something you want to try now while I'm still up?
[02:25] <plars> thomi: I think as long as we get through the install, we will know we're good
[02:25] <thomi> plars: sure, I'll kick it off again
[02:25] <plars> I'm going to add that device to the pool too, since it's there for now
[02:26] <thomi> http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/116/ is running
[02:26] <thomi> + ubuntu-device-flash ubuntu-system --channel ubuntu-touch/utopic-proposed --bootstrap
[02:26] <thomi> looks good to me :)
[02:27] <plars> heh, as luck would have it, it ended up picking mako-07 anyway, but it picked it from the pool this time :)
[02:27] <plars> it's flashing utopic though, so all good
[02:28] <plars> Saviq: you can specify the channel on the autopilot gatekeeper job now, and default is utopic-proposed
[02:28] <plars> thanks thomi
[02:28] <thomi> I'll wait till it starts installing packages, just to make sure it picks up the correct ap packages
[02:42] <thomi> plars: still around?
[02:43] <thomi> I think phablet-test-run isn't using the correct autopilot version
[02:46] <robotfuel> thomi: is that for click packages?
[02:47] <thomi> robru: ubuntuuitoolkit ATM
[02:47] <thomi> surely that's ported to py3
[02:47] <thomi> it'd have to be, for anything else to use it
[02:47] <thomi> well, I guess it's bilingual
[02:47] <thomi> but I expected bilingual ports to use py3
[02:49] <robotfuel> thomi: I found out yesterday that phablet test run needed to have a test section in the manifest for it to use py3
[02:50] <thomi> robotfuel: yeah, xnox told me that as well. I'll keep an eye on this run and see what happens
[02:50] <robotfuel> thomi: https://code.launchpad.net/~xnox/gallery-app/py3-manifest is an example
[02:50] <thomi> yup
[03:00] <plars> thomi: sorta
[03:01] <thomi> plars: nvm, I'll pick it up again tomorrw
[03:01] <thomi> gonna let the test job finish
[03:01] <thomi> thanks for your help :)
[03:01] <plars> thomi: anytime :)
[03:01] <plars> good night
[03:02] <thomi> 'night
[03:24] <imgbot> [03:24] <imgbot> [04:11] <Mirv> choo choo
[06:49] <Saviq> plars, thanks!
[08:11] <sil2100> cjwatson: hello! Could you by any chance help me out on understanding the ubuntu-download-manager autopkgtest failure? It doesn't seem like a valid failure to me on first look, seems more like some infra problem - what do you think? Example logs: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-system-image/4/ARCH=amd64,label=adt/console
[08:12] <dpm> morning psivaa, could we trigger Jenkins on https://code.launchpad.net/~akiva/reminders-app/fix-1316827-reload-notes/+merge/218566 ? I think it didn't run because the MP came from a contributor outside the development team
[08:12] <psivaa> dpm: just a sec pls
[08:13] <dpm> no worries, thanks!
[08:13] <popey> psivaa: could you please look at why sudoku-app isn't building in jenkins - http://s-jenkins:8080/job/sudoku-app-click/lastUnsuccessfulBuild/console
[08:13] <popey> bzr: ERROR: Already a branch: "/home/ubuntu/jenkins/workspace/sudoku-app-click/tool_dir".
[08:13] <popey> (morning btw)
[08:13] <psivaa> popey: morning. ack will take a look
[08:24] <Mirv> was the friends app discussed in the evening btw? I can confirm that it's indeed broken for me at least, like the autopilot say too, after the new 0.92.0+14.10.20140506.1 release
[08:25] <Mirv> mardy: ^
[08:26] <sil2100> Mirv: I don't remember hearing about it
[08:26] <Mirv> oh, hmm, going over it again, is it because ubuntu-system-settings-online-accounts is stuck in propose?
[08:26] <Mirv> autopkgtest failed
[08:26] <Mirv> https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/4/ARCH=amd64,label=adt/console
[08:28] <Mirv> so the landing got partially stuck
[08:28] <sil2100> Yeah, I noticed that in the morning alongside other failures
[08:29] <sil2100> This one seems like a real failure though?
[08:29] <sil2100> Let's discuss that on the meeting
[08:29] <psivaa> popey: http://s-jenkins.ubuntu-ci:8080/job/sudoku-app-click/119/console has some errors in the sudoku app code
[08:30] <psivaa> dpm: still looking at the MP. i'll see if i can trigger without adding the proposer without adding to the group
[08:30] <popey> psivaa: thanks
[08:31] <dpm> thanks psivaa
[08:31] <ogra_> grr
[08:32] <ogra_> no alarm ...
[08:38] <mardy> Mirv: mmm... you mean that friends-app landed, while the other bits in the same silo (like ubuntu-system-settings-online-accounts) didn't?
[08:41] <davmor2> popey: why are you accepting bribes on my behalf :)
[08:43] <popey> ☻
[08:43] <davmor2> popey: do you have the bug available for the download bar vanishing on update manager
[08:43] <Mirv> mardy: yes. or the u-s-s-o-a landed but is stuck in proposed because its autopkgtest is failing (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
[08:44] <Mirv> so friends is broken because it didn't declare a dependency on the newer u-s-s-o-a
[08:44] <popey> davmor2: depends which bug - the one where the content disappears?
[08:47] <mardy> Mirv: I can't understand the failure in the u-s-s-o-a tests, it looks like something is missing but I'm not sure what
[08:48] <popey> psivaa: when you get a moment could you retrigger jenkins on this merge, or tell me how to? https://code.launchpad.net/~popey/sudoku-app/fix-1315318/+merge/218035
[08:48] <mardy> Mirv: is it correct to run the autopilot tests in the autopkg tests?
[08:51] <davmor2> popey: so you click on update you see the download bar initially and then it disappears.  I don't see it on mako but it happens on flo and manta reliably :)
[08:51] <popey> i have seen it on mako and flo
[08:52] <popey> bug 1307687
[08:56] <psivaa> popey: I see you dont have access to that instance of jenkins. i've kicked off a rebuild. i'll see if i can add your account to it
[08:59] <Mirv> mardy: I think so yes, even though my autopkg knowledge is limited. they should be executed in full graphical lxc environment.
[08:59] <Mirv> mardy: but pitti mentioned earlier that there were some changes https://lists.ubuntu.com/archives/ubuntu-devel-announce/2014-May/001098.html
[09:00] <popey> psivaa: thank you!
[09:01] <psivaa> np
[09:05] <cjwatson> sil2100: That does look somewhat bogus; have you tried running the test locally?
[09:09] <davmor2> popey: mtp died on me too so confirmed the bug
[09:09] <popey> thanks
[09:10] <popey> have assigned it to cyphermox
[09:10] <davmor2> popey: yeah I can't even reattach to mtp now
[09:11] <popey> davmor2: we should add a task in the manual test sheet for this.
[09:11] <popey> also, probably need a test for "upgrading an app from the store" which would mean we probably need an app which we can install an old version of, to force there to be an update
[09:17] <thostr_> sil2100: line 20 is now good to get a silo
[09:18] <thostr_> sil2100: however, not sure if that requires explicit qa signoff (a lot of refactored code). what's the policy here?
[09:21] <Mirv> thostr_: we get the pings automatically on #ubuntu-ci-choo-choo channel when a line is set to ready
[09:22] <Mirv> thostr_: I think qa signoff is only for trusty SRU:s as it was introduced for finalizing the new stable image
[09:22] <Mirv> silo assigned
[09:22] <thostr_> Mirv: thanks for clarifying
[09:29] <cjwatson> Doesn't look like it's been mentioned here: the publisher will be stopped for the next five hours or so (technically, it's in the middle of a very very long run) because we're processing a takedown request and the caches for several of the affected suites were absent.
[09:38] <Wellark> hey, what's this?
[09:38] <Wellark> http://changelogs.ubuntu.com/changelogs/pool/universe/q/qmenumodel/qmenumodel_0.2.7+14.04.20140305-0ubuntu2/changelog
[09:38] <Wellark> that latest version
[09:38] <sil2100> thostr_: I switched the QA sign-off to No today, as we only do that when there is a critical situation with no-propotions
[09:38] <Wellark> it's not in trunk
[09:38] <Wellark> and now silo9 fails
[09:38] <Wellark> with WARNING A version (0.2.7+14.04.20140305-0ubuntu2) is available at the destination archive for that component but is not in the destination branch which is still at 0.2.7+14.04.20140305-0ubuntu1. You need to ensure that your version contains the fix in the destination or you can force rebuild to bypass the check.
[09:39] <psivaa> dpm: so i've kicked off a build manually for Akiva's proposal. http://<IP_ADDRESS>:8080/job/reminders-app-ci/309/console
[09:39] <Laney> you can bypass no-change rebuilds imo
[09:40] <psivaa> dpm: it should work, but if it's not, some one has to approve the membership request
[09:40] <Wellark> cjwatson: what takedown request? is there a public bug for it?
[09:40] <cjwatson> Wellark: https://bugs.launchpad.net/ubuntu/+source/maitreya/+bug/1317234
[09:42] <sil2100> Wellark: so, this message basically means that someone made a direct release to the archive without merging in the changes to the bzr branch
[09:42] <sil2100> Wellark: so most likely 0.2.7+14.04.20140305-0ubuntu2 got released manually and there is no 0.2.7+14.04.20140305-0ubuntu2 in the bzr branch for that component
[09:42] <Wellark> sil2100: yes. as I noted, the 0ubuntu2 is not in trunk
[09:42] <Wellark> so how to proceed now?
[09:43] <dpm> psivaa, thanks. It seems all jobs failed, not sure why -> https://code.launchpad.net/~akiva/reminders-app/fix-1316827-reload-notes/+merge/218566/comments/521402
[09:43] <Laney> I'd say that is to be expected for no change rebuilds, and should be ignored at train level (which will discard the changelog entry, but that's fine)
[09:43] <sil2100> What needs to be done is you (or anyone else) need to, for instance, prepare a merge that actually 'adds' this missing changes and the changelog entry from the archive
[09:45] <Wellark> sil2100: so I just get the archive source package, copy over it's debian/changelog and commit. ok. thanks!
[09:46] <psivaa> dpm: there is another build ongoing. i dint enter the parameters in the first build properly
[09:46] <dpm> psivaa, ok, no worries. I had top-approved it too, not sure if that will help or interfere
[09:46] <sil2100> Wellark: yes, that's the best way :) Just getting the changes as a merge and adding them to your landing as the first merge
[09:47] <Wellark> sil2100: it has to be a separate MP?
[09:48] <Wellark> can't I just make a commit to the MP that I have proposed for landing?
[09:51] <sil2100> Wellark: it can, no problem
[09:51] <sil2100> Wellark: am a bit worried about the changelog generation, but I guess we'll see how it goes
[09:52] <Wellark> ok. let's see
[09:55] <Wellark> sil2100: ok. done. could you tricker a rebuild of silo9?
[09:57] <sil2100> Wellark: sure
[09:58] <Wellark> sil2100: thanks!
[10:02] <popey> psivaa: could you also re-trigger https://code.launchpad.net/~gang65/ubuntu-docviewer-app/ubuntu-docviewer-desktop-improvements/+merge/210866 ?
[10:03] <psivaa> popey: done
[10:03] <popey> thanks psivaa
[10:13] <Wellark> sil2100: ... https://ci-train.ubuntu.com/job/landing-009-1-build/62/console
[10:14] <sil2100> Wellark: yeah, was a bit worried this might happen, not a big deal though - let me find the best solution here
[10:14] <Wellark> sil2100: so I need to change the 0ubuntu2 to UNRELEASED and also use dch -i
[10:14] <sil2100> No no no
[10:14] <Wellark> that what the message says! ;)
[10:14] <sil2100> Leave 0ubuntu2 as it is, as it was released, so it cannot be UNRELEASED anymore ;) It needs to stay as utopic
[10:14] <sil2100> What would be best to do is:
[10:15] <sil2100> (this is the safest way)
[10:16] <sil2100> Now that you have 0ubuntu2 in as 'utopic', go to the source tree and do a dch -i (to generate 0ubuntu3) and write the commit message manually there
[10:16] <sil2100> i.e. copy-and-paste the commit message as a changelog entry for 0ubuntu3
[10:16] <sil2100> And leave 0ubuntu3 as UNRELEASED
[10:16] <Wellark> but will I leave 0ubuntu2 there?
[10:17] <sil2100> Yes, leave 0ubuntu2 in there as it was in the archive
[10:17] <Wellark> so 0ubuntu3 contains the commit message from my MP?
[10:17] <sil2100> Yes, with the addition of 0ubuntu3 on top with your changelog entry from the commit message
[10:18] <sil2100> citrain, during release, will change the version number of 0ubuntu3 to a proper one and change it to 'utopic' during release, just we need to make sure it doesn't mess up the changelog
[10:19] <sil2100> (there is a high-chance that citrain would handle this correctly, but it's best to be sure)
[10:20] <sil2100> Wellark: so, just dch -i in your branch now, add the commit message as the changelog entry, commit, push and let's rebuild
[10:20] <Wellark> sil2100: please make a sanity check: https://code.launchpad.net/~kaijanmaki/qmenumodel/unitymenumodel_setname-allow-empty-string/+merge/213768
[10:22] <sil2100> Wellark: looks awesome, just one thing that needs to be changed - the actual changelog entries have to be wrapped at 80 characters
[10:23] <Wellark> oh, com'on!
[10:23] <Wellark> ;)
[10:23] <Wellark> will do.
[10:23] <sil2100> Wellark: so do this: http://paste.ubuntu.com/7415234/
[10:23] <sil2100> ;)
[10:23] <sil2100> Sorry, otherwise it might cause trouble ;p
[10:23] <sil2100> But besides that we're ready to build
[10:24] <Wellark> sil2100: pushded
[10:25]  * Wellark wonders if we are still stuck to 80 characters in 2036
[10:25] <sil2100> I guess we will ;p
[10:25] <davmor2> popey: your screenshot script do you see this remote object '/tmp/mir_screencast_768x1280.rgba' does not exist
[10:26] <sil2100> Wellark: ok, rebuilding
[10:26] <Wellark> sil2100: thanks!
[10:26] <popey> they added _60Hz to the filename davmor2
[10:26] <sil2100> yw!
[10:26] <davmor2> popey: ah ta
[10:27] <Wellark> sil2100: looks like Saviq just hit the same problem
[10:27] <Wellark> https://ci-train.ubuntu.com/job/landing-010-1-build/11/console
[10:28] <Wellark> could we please not do manual uploads in the future... :)
[10:28] <sil2100> Wellark: *sigh* this is the biggest problem - manual uploads wouldn't be a problem if they would be later merged-back into trunk
[10:29] <Saviq> nasty
[10:29] <Wellark> sil2100: if it's just a rebuild upload
[10:30] <Wellark> what about pushing the debian changelog entry directly to trunk?
[10:30] <Wellark> would be easiest
[10:30] <sil2100> Wellark: that could be done as well, yes - there's also another thing we were doing, but core-devs generally frowned upon that ;p
[10:31] <sil2100> Wellark: since in the past we basically 'forced' ignoring that version, just pushing without that changelog entry
[10:31] <sil2100> It would work, as if it's just a rebuild, there is no risk involved - but you basically 'remove that version from history', which is bad
[10:31] <Wellark> these changes are not even simple rebuilds
[10:31] <Wellark> they actually modify debian/control
[10:31] <Wellark> http://changelogs.ubuntu.com/changelogs/pool/universe/libu/libusermetrics/libusermetrics_1.1.1+14.04.20140305-0ubuntu4/changelog
[10:32]  * Wellark looks for a fresh trout
[10:33] <Wellark> sil2100: did you tick "reconfigure" on my silo yet?
[10:34] <Wellark> or is it "build"
[10:34] <Wellark> anyway..
[10:34] <sil2100> Wellark: yes ;) It's building
[10:34] <Wellark> sil2100: thanks!
[10:35] <Wellark> let's see what the next error is..
[10:55] <Wellark> sil2100: what does this now mean... https://ci-train.ubuntu.com/job/landing-009-1-build/63/console
[10:56] <sil2100> Another error?! Let me look in a moment
[10:56] <sil2100> Oh, connectivity-api now, let's see
[10:57] <sil2100> uh
[10:57] <Wellark> sil2100: wait..
[10:57] <sil2100> So, looking at the connectivity-api merge, there's some strange changelog magic there o_O
[10:57] <Wellark> for some reason there is a change to debian/changelog as part of the MP
[10:58] <sil2100> I guess that's something that's not needed, I would remove that
[10:58] <Wellark> sil2100: yeah..
[10:58] <Wellark> weird..
[11:01] <Wellark> sil2100: ok. fixed.
[11:02] <Wellark> sil2100: could you do a reconfigure while you are at it?
[11:03] <Wellark> I merged some tests from dednick to the unity8 branch
[11:03] <Wellark> oh, actually
[11:03] <Wellark> never mind
[11:03] <Wellark> didn't push them yet
[11:03] <sil2100> Wellark: did you add a new merge? :)
[11:03] <sil2100> A reconfigure is needed only when a new merge is added to the list of merges
[11:03] <Wellark> ah, ok
[11:03] <sil2100> Otherwise a rebuild is all that's needed
[11:03] <Wellark> ok. cool.
[11:04] <sil2100> Should I wait for you to push those changes?
[11:04] <Wellark> rebuild then pleae :)
[11:04] <Wellark> nope.
[11:04] <Wellark> I'm fighting with ssh-agent
[11:04] <Wellark> need to remove gazillion of tags from a remote branch
[11:04] <Wellark> and bzr is asking for my ssh key passphrase on each removal for some reason
[11:10] <Wellark> sil2100: let's see what happends next.. :)
[11:10] <Wellark> maybe my c++11 monster will hit OOM on the arm builders or something..
[11:21] <davmor2> ogra_: do you have a manta?
[11:25] <sil2100> cjwatson: hi! So I ran the system-image autopkg tests locally and everything is passing correctly - I would say this was some transient issue, do you know if we can somehow re-run those to get it move out of -proposed?
[11:25] <sil2100> cjwatson: ubuntu-download-manager has no autopkg tests of its own, it was the system-image ones that seemed to have failed there
[11:26] <sil2100> cjwatson: I'm still a bit of a newbie here, but I guess it would be nice to have that re-ran if possible
[11:26] <sil2100> (not even sure who to ping?)
[11:28] <cjwatson> I can re-run them
[11:29] <cjwatson> sil2100: build scheduled.  in general you want to ask pitti/jibel for autopkgtest stuff though
[11:29] <cjwatson> sil2100: but didn't pitti point out a problem on another channel though?
[11:29] <cjwatson> it would be nice not to have this conversation spread across channels
[11:30] <sil2100> cjwatson: ok thanks! Yes, but I can't really fix that, and running locally seemed to work - and I also poked pitti but he seems to be AFK ;)
[11:30] <cjwatson> but pitti answered you and suggested a specific change to make
[11:30] <cjwatson> you could just wait for system-image people to wake up, since it's not like you're going to get anything moved out of -proposed right now anyway with the publisher in the middle of a very long run
[11:30] <sil2100> cjwatson: yes, but how could I change that, as it's a test in system-image, which I do not have commit-access to
[11:31] <cjwatson> it sounds like the rerun I just scheduled was a waste of time since it'll fail in the same way
[11:31] <sil2100> cjwatson: and as I mentioned, it passed locally, so I guess if it was a real problem as outlined it would have failed for me as well I would suppose
[11:31] <cjwatson> the comments from pitti on #ubuntu-devel don't suggest that it was transient
[11:31] <cjwatson> no, not necessarily
[11:33] <cjwatson> depends on the test runner
[11:33] <cjwatson> oh, that said, amd64 passed ...
[11:34] <sil2100> Oh
[11:34] <sil2100> So... even I didn't really expect that
[11:34] <sil2100> ;p
[11:34] <cjwatson> ... and so did i386
[11:34] <cjwatson> so ok :)
[11:34] <sil2100> I wonder why it didn't pass before then
[11:34] <cjwatson> beats me
[11:35] <sil2100> cjwatson: thanks and sorry for poking around, now at least I know who to contact best ;)
[11:35] <cjwatson> anyhow, yeah, core devs / release team types should generally be able to rerun jobs
[11:35] <cjwatson> pitti/jibel operate the infrastructure
[11:36] <cjwatson> I think only Canonical members of the above teams can rerun jobs, at the moment, since Jenkins
[11:36] <Laney> Indeed, because you need to use an instance behind a private VPN to do that
[11:38] <davmor2> popey: https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1317480
[11:39] <davmor2> popey: no idea why but manta hates your screenshot script in the end I had to modify the phablet-screenshot script and that eventually worked :) but I got there
[11:39] <ogra_> what did you have to change ?
[11:56] <davmor2> ogra_: _60Hz to adb pull line
[11:56] <ogra_> davmor2, ah, good ... just porposed an MP for that
[11:56]  * ogra_ was just scared there was something else
[11:59] <davmor2> ogra_: no it worked fine once I'd found the script and modded it.  popey's from what I can tell mirrors it only uploads them to a server via ssh at the same time.  The only issue is that manta spits it's dummy out with the first adb command even though I changed the size to match the image name and added the _60Hz :(
[11:59] <ogra_> yeah, https://code.launchpad.net/~ogra/phablet-tools/force-mirscreencast-filename/+merge/218788 fixes that
[12:33] <popey> davmor2: i am getting no notification sounds in #17 on mako when I get an SMS
[12:36] <davmor2> popey: I had that too the other day but then I think I rebooted and it went away let me check though
[12:36]  * popey reboots to test
[12:36] <ogra_> did you guys get a meeting notification this morning ?
[12:36] <ogra_> i didnt on #15
[12:37] <popey> i did for one meeting, not for another
[12:37] <popey> yeah, reboot and the ding comes back
[12:37] <davmor2> popey, ogra_: so I got the first but not the second
[12:38] <ogra_> so there is still something odd ... i would put my bets on that it is the same thing
[12:38] <davmor2> and now I can't send a reply from the indicator
[12:39] <davmor2> popey, ogra_: okay I've had no pings since the first
[12:41] <popey> davmor2: ogra_ can either of you confirm bug 1317510
[12:42] <sil2100> popey: if reboot helps then its NOTABUG
[12:42] <sil2100> ;p
[12:43] <popey> :þ
[12:43] <davmor2> popey: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-05-08-134309.png I get a mix
[12:44] <davmor2> popey: I'm assuming ones with alarms have the alarm icon and the ones that are just dates don't
[12:45] <davmor2> popey: send a second text
[12:45] <popey> i have sent a few
[12:46] <mandel> sil2100, any news about silo 001
[12:46] <davmor2> ogra_: for the meeting tomorrow morning on the phone look and see if it is the alarm clock or the calendar app icon in the date/time indicator
[12:47] <sil2100> mandel: so! All is good now, with the help of cjwatson and pitti in the end a re-run helped - but it might take a while until it migrates
[12:47] <sil2100> mandel: since the publisher seems to be in the middle of something long
[12:47] <davmor2> ogra_: see my screenshot in comparison to popey 's
[12:48] <ogra_> davmor2, i only have clocks
[12:48] <mandel> sil2100, great, that means that I just have to wait for the bot to let me know is publish and I can free the silo, awesome
[12:49] <dpm> hi psivaa, I've got another MP from someone outside the dev team, which means Jenkins won't run automatically. I've top-approved it now - will Jenkins do the autolanding, or does it need to be triggered manually? -> https://code.launchpad.net/~dholbach/reminders-app/some-lintian-fixes/+merge/218792
[12:51] <psivaa> dpm: ok, i think this issue could be easily solved by adding dholbach to the app developers group.
[12:51] <psivaa> fginther: ^^ does that sound doable?
[12:52] <fginther> dpm, if you've top approved it, jenkins will pick it up
[12:52] <dpm> psivaa, right, but I'd prefer not to have to add any folk that sends a MP to the team. I'd like to add them once they've done more sustained contributions
[12:53] <dpm> fginther, psivaa, ok, then top-approval works for me, thanks!
[12:53] <psivaa> dpm: fginther: ack, thanks
[13:06] <Wellark> hello!
[13:06] <Wellark> just wondering
[13:06] <Wellark> https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/+packages
[13:06] <Wellark> indicator-network depends on connectivity-api on that same silo
[13:06] <Wellark> and now indicator-network build fails as connectivity-api is not built before it
[13:07] <Wellark> is it just enough to tricker a rebuild once connectivity-api has fully built?
[13:07] <Wellark> or in other words: do the old packages stay in the ppa when rebuild is trickered?
[13:08] <Wellark> + another guestion, is it possible to rebuild just one of the packages?
[13:16] <Wellark> sil2100: ^
[13:17] <sil2100> Wellark: first answering the last question: yes, you can force a rebuild of only one package ;)
[13:17] <sil2100> As for the rest, let me take a look
[13:18] <sil2100> Oh
[13:18] <sil2100> Wellark: so, in case indicator-network requires a newer connectivity-api, then we would need the build-dependencies to be bumped
[13:19] <sil2100> Wellark: if the dependencies would be correct, then even if the packages are built out-of-order, it would only enter a dep-wait
[13:19] <Wellark> gah.. it's private api..
[13:20] <Wellark> and no different from a situation when there is a crash for example where you need to land two depending packages at the same time
[13:20] <Wellark> sil2100: can't you just kick a rebuild of the indicator-network package on that silo?
[13:22] <sil2100> Wellark: hm, need to think about that, since I'm always a bit weary about having a case where theoretically someone would be unable to build indicator-network with dependencies properly installed
[13:23] <sil2100> Since for me if something doesn't build with an older version means that we need the build-deps bumped
[13:23] <sil2100> BUt I need to think if it's a big of a deal
[13:24] <Wellark> the whole marvel of ci train compared to the previous process is that we can actually make a coordinated landing of separate components without doing such bumps etc. if they are not absolutely necessary
[13:24] <Wellark> sil2100: it's perfectly safe for this landing
[13:25] <Wellark> as long as indicator-network and connectivity-api from that ppa hit the archive atomically
[13:25] <Wellark> "atomically"
[13:26] <sil2100> This is the point - we can't guarantee that anymore, one of them can get blocked in -proposed by some freak accident
[13:26] <sil2100> Just as what happened due to autopkgtest problems
[13:26] <sil2100> Let me simply ask a core dev about opinion and then proceed :)
[13:27] <Wellark> well, freak accident sounds like unlikely breakage that most probably breaks stuff anyway ;)
[13:37] <Wellark> sil2100: any resolution?
[13:38] <sil2100> One moment, just finishing my meeting!
[13:38] <Wellark> oh, ok
[13:39] <bzoltan> sil2100: Mirv: what do I do wrong? http://pastebin.ubuntu.com/7416073/
[13:46] <ogra_> Wellark, just use a versioned build dep ... thats why we can use these ;)
[13:47] <ogra_> if a version has a new feature you need to make your package not FTBFS it is pretty clear you need to add a ( >= $version) to your build deps ...
[13:47] <ogra_> especially since (if your packaging is proper) your binary deps will be generated from this
[13:53] <sil2100> Wellark: so, I don't think there's a general policy to block on this, but I think we would really prefer the deps being bumped ;p
[13:53] <sil2100> (the landing team is a bit pickish as well... ;p)
[13:53] <sil2100> And yes, by 'landing team' right now I basically mean myself
[13:53] <sil2100> ;p
[13:54] <ogra_> well, if he wants to fix his FTBFS he needs to add that dep
[13:54] <ogra_> policy or not
[13:54] <ogra_> :)
[13:54]  * ogra_ thinks thats pretty obvious and nothing to waste time to discuss about :)
[13:58] <Wellark> right, you mean just adding a version to build dep
[13:58] <Wellark> that I can do
[13:58] <ogra_> yeah with a gtreater-equals ... (>= ... )
[13:58] <Wellark> I'm just against bumping the package/so-name if it's not absolutely necessary
[13:58] <sil2100> I didn't mean that ;)
[13:58] <sil2100> I just wanted the build-dep to be bumped
[13:59] <Wellark> well, can't reallly do the = part
[13:59] <Wellark> as I can't know what the last will be
[13:59] <sil2100> Just do this >= 0.0.1+14.10.20140508.1-0ubuntu1  I guess
[13:59] <Wellark> oh, there was a variable for that
[13:59] <Wellark> should be enought to do > $latest_released_version though..
[14:00] <Wellark> but but
[14:00] <Wellark> dpkg should offer a $version or something
[14:00] <cjwatson> man deb-substvars
[14:00] <Wellark> oh, but that's inside a package
[14:00] <cjwatson> but you can't do that in build-deps
[14:00] <sil2100> I think if you mark it as (>= 0.0.1+14.10.20140508.1-0ubuntu1) it's good idea
[14:00] <Wellark> yeah
[14:00] <cjwatson> for build-deps just remember that the version you use in >= does not actually have to exist
[14:00] <Wellark> indeed
[14:01] <sil2100> Wellark: since any further re-builds will be anyway greater than this
[14:01] <cjwatson> you just need to predict what the train will do, roughly
[14:01] <sil2100> As cjwatson says :)
[14:01] <Wellark> cjwatson: ok, so I can just take $today and slam it in
[14:01] <cjwatson> you shouldn't use >> $latest_released_version because that will do the wrong thing if somebody else needs to do a no-change rebuild before you land
[14:01] <Wellark> but the same would basically be archived by doing ">$last_version_in_debian_changelog"
[14:02] <Wellark> oh, right
[14:02] <sergiusens> maybe the citrain should do this automatically regardless (I might be opening a can of worms though) or with a toggle or heuristics from the packages to be built (check build deps for packages in the same silo)
[14:03] <Wellark> sil2100: if I promise to do this on next reconfigure, could we just get the package to be built in the silo for now to enable testing.
[14:03] <cyphermox> ideally you'd probably want to use a specific new upstream version for the thing you're depending on, if it's part of the landing; that way unless someone actually goes out to bump the upstream version (ie. I don't know, 1.05 instead of 1.0) then >= 1.05 is both short and would work
[14:04] <Wellark> I'm pretty sure I need to modify the branches a bit as somebody will dig up a problem
[14:04] <cjwatson> cyphermox: yeah
[14:05] <cyphermox> for major features, it's worth it, i think
[14:05] <cjwatson> also much easier to spot visually
[14:05] <cyphermox> yup
[14:05] <sil2100> Wellark: in this case, as I said, you just need to mention a near version of the package that citrain will generate
[14:05] <cyphermox> also easier to predict than the dates from train landings
[14:07] <sil2100> Wellark: no need to try and resolve it in some special way - sometimes the easiest methods are the safest ;) And yeah, I can rebuild it if you promise to push this dependency version bump ASAP and request a rebuild then
[14:07] <Wellark> sil2100: I promise
[14:07] <sergiusens> sil2100: the changelog looks screwed up in my silo https://launchpad.net/~ci-train-ppa-service/+archive/landing-014/+packages
[14:08] <sergiusens> sil2100: it's two MPs, one a prereq of the other
[14:08] <sil2100> Wellark: let me rebuild then, thanks!
[14:08] <sergiusens> sil2100: they show the same changelog entry for ogra_ and me which is the one from the latest MP
[14:08] <sil2100> sergiusens: hm, let me take a look in a moment, we seemed to have some problems with changelogs before, but one moment
[14:09] <ogra_> yeah, that looks wrong
[14:09] <ogra_> CI bot stole my message actually
[14:10] <bfiller> sil2100: can you check on silo 4, been marked as waiting for a package to reach destination for a while
[14:10] <bfiller> since yesterday
[14:10] <sil2100> bfiller: ah yeah, so... I wanted to have a talk with you about that one
[14:11] <sil2100> bfiller: one moment though
[14:13] <cjwatson> free
[14:14] <cjwatson> sorry
[14:14] <cjwatson> muttermutterbuggyfocus
[14:14] <cyphermox> awe_: hey
[14:14] <awe_> morning
[14:14] <awe_> fm silo?
[14:14] <cyphermox> awe_: line 28; am I forgetting something for a flight mode landing?
[14:14] <cyphermox> well, just preparing the stuff really
[14:14] <cyphermox> telepathy-ofono and urfkill? do we need ofono too?
[14:14] <sil2100> sergiusens: so, this might actually be a bug
[14:15] <awe_> no ofono changes needed
[14:15] <cyphermox> ok
[14:15] <sil2100> sergiusens: I need to take a look what's happening inside, since I can't think of a reason why that's happening
[14:15] <cyphermox> so just tp-ofono and urfkill then
[14:15] <awe_> yup, and nm if needed
[14:15] <cyphermox> nm already landed with MMS
[14:15] <awe_> ok
[14:16] <cyphermox> can you poke tiago?
[14:16] <awe_> sure...
[14:16]  * cyphermox will prepare for the meeting while the emulator still attemps to start
[14:17] <sil2100> bfiller: so! Regarding those packages blocked in -proposed
[14:18] <sil2100> bfiller: the situation is a bit dire, wanted to have a chat with you and cjwatson if he has a free moment
[14:18] <sergiusens> sil2100: free free to rebuild when fixed
[14:18] <cjwatson> sil2100: Is it?  You certainly don't have up-to-date data because of the long publisher run
[14:19] <cjwatson> (which looks nearly complete ...)
[14:19] <sil2100> bfiller: since with the introduced new dependency (address-book-app now depends on parts of ubuntu-keyboard), some address-book-app binaries are now not installable on some platforms
[14:19] <sil2100> cjwatson: I checked on the source side and it seems to still be a problem...
[14:19] <sil2100> bfiller, cjwatson: since now address-book-app stops being buildable on ppc64el (and others), which means dialer-app and messaging-app would become not buildable for those architectures as well
[14:20] <cjwatson> Can you point me to the build for that?
[14:20] <sil2100> bfiller, cjwatson: since right now address-book-app depends on ubuntu-keyboard which depends on mir-specific bits
[14:20] <sil2100> And dialer-app and messaging-app depend on address-book-app
[14:20] <sil2100> cjwatson: one moment
[14:20] <cjwatson> Because https://launchpad.net/~ci-train-ppa-service/+archive/landing-004/+build/5984838 built on ppc64el
[14:21] <cjwatson> (that's the current version in -proposed)
[14:21] <sil2100> Oh
[14:21] <sil2100> In the morning it wasn't the case
[14:22] <sil2100> Let me take another look then
[14:22] <cjwatson> Oh, you're not talking about buildability, I think
[14:22] <cjwatson> "address-book-app/arm64 unsatisfiable Depends: qtdeclarative5-ubuntu-keyboard-extensions0.1" etc?
[14:23] <cjwatson> So buildable but not installable
[14:23] <sil2100> cjwatson: yes, right, sorry if I wrote it wrong
[14:23] <cjwatson> Give me a minute to investigate
[14:24] <sil2100> qtdeclarative5-ubuntu-keyboard-extensions0.1 is not available for arm64 and others, which makes parts of address-book-app not installable on those platforms anymore, which would then probably mean not being able to install messaging-app and dialer-app (need to re-check that last thing though)
[14:24] <sil2100> No, actually the last thing is not the case I guess
[14:24] <cjwatson> dialer-app and messaging-app, yes
[14:24] <sil2100> Ooor...
[14:24] <cjwatson> You were right the first time
[14:24] <renato_> sil2100, this package is inside of the same silo (004)
[14:27] <cjwatson> I'm looking into a workaround
[14:27] <sil2100> cjwatson: thanks! Do you have any particular ideas on how to deal with this?
[14:28] <cjwatson> Well, the address-book-app dependency is real, but I think we could keep on building qtdeclarative5-ubuntu-contacts0.1 on all architectures but restrict address-book-app{,-dbg} to amd64 armhf i386
[14:28] <cjwatson> Testing this theory
[14:33] <elopio> cjohnston: ping. We are seeing an error on Jenkins while adding an online account.
[14:33] <elopio> it could be because the keyring is not unlocked. I need some help with this.
[14:33] <cjohnston> link?
[14:34] <elopio> cjohnston: http://<IP_ADDRESS>:8080/job/generic-mediumtests-utopic/45/testReport/reminders.tests.test_reminders/RemindersTestCaseWithAccount/test_open_application_with_account_with_mouse_/
[14:35] <elopio> the first thing to check would be if the keyring is locked or not on the runners.
[14:35] <elopio> mardy says that on lightdm, it's unlocked when you log in, so that might be why I don't see the problem on my machine or my phone.
[14:36] <cjwatson> sil2100: https://code.launchpad.net/~cjwatson/address-book-app/arch-limits/+merge/218818
[14:36] <cjohnston> there appears to be some sort of issue around stoping lightdm/"start_x"
[14:42] <sil2100> cjwatson: ok, this should fix it indeed, need to now somehow re-push it using the train
[14:42] <sil2100> cjwatson: can I make a separate merge out of it and add it to that landing?
[14:42] <cjwatson> Feel free to do whatever's needed to land it; I'm not protective of it :)
[14:43] <sil2100> Or Oh, wait
[14:43] <cjwatson> (But I also don't know exactly what would be needed)
[14:43] <sil2100> No, actually it looks good, what's with my eyes today...
[14:43] <sil2100> Let me try getting it into the silo - might take some moments
[14:43] <sil2100> cjwatson: thanks!
[14:43] <cjwatson> Let me know if/when it's in -proposed so that I can do the binary cleanup
[14:44] <cjwatson> I think the publisher should be back up relatively soon
[14:46] <sil2100> Not to bother cjwatson all the time, ogra_ could I ask you for a packaging ACK for a quick change in unity8? It's for the bottom-edge HUD removal: https://ci-train.ubuntu.com/job/landing-005-2-publish/25/artifact/packaging_changes_unity8_7.86+14.10.20140507.3-0ubuntu1.diff
[14:46] <sil2100> Looks ok, no-brainer change it seems
[14:47] <ogra_> you just dont want to bother cjwatson with having to use 2fa crap :P
[14:47] <ogra_> sil2100, ack, looks ok
[14:47] <sil2100> ;p
[14:47] <Saviq> thostr_, you'll need to rebuild unity8 in silo 009, not sure why we have a conflict there
[14:48] <Saviq> thostr_, but silo 005 is up for publishing
[14:48] <Saviq> mhr3, ↑
[14:48] <thostr_> Saviq: arg...
[14:50] <mhr3> as always thostr_ hogging unity8
[14:50] <mhr3> :P
[14:51] <thostr_> mhr3: have you said anything?
[14:51] <mhr3> me?
[14:51] <mhr3> no
[14:51] <thostr_> good :)
[14:52] <cjohnston> elopio: still investigating
[14:52] <elopio> cjohnston: thanks.
[14:52] <elopio> balloons, dpm: ^ that's for the reminders failure in jenkins.
[14:52] <cjohnston> elopio: this is a new test?
[14:53] <balloons> elopio, ohh we're doomed if cjohnston is on the case :-)
[14:53] <balloons> ty cjohnston for having a look!
[14:53] <dpm> ok, thanks elopio
[14:53] <elopio> cjohnston: yes, it's a new test.
[14:53] <elopio> the first time we are adding an online account.
[14:54] <fginther> elopio, what keyring lock is this using? is there a way for me to check if it is locked?
[14:54] <elopio> fginther: I don't know.
[14:55] <elopio> we are assuming the keyring is unlocked.
[14:57] <sil2100> popey: how's testing #17 going so far?
[14:59] <popey> sil2100: seems okay.
[15:00] <fginther> elopio, this may be a problem due to auto-login. These test machines are supposed to be set to auto-login which appears to force the keyring locked
[15:00] <popey> however...
[15:00] <popey> one issue I have had twice is difficulty dismissing notifications
[15:00] <sil2100> Oh?
[15:01] <popey> yeah, two different things, hard to reproduce
[15:01] <popey> brb, meeting
[15:01] <elopio> fginther: that's what mardy suspects. Should I unlock the keyring on the test somehow, or should the machine be configured to start the test unlocked?
[15:01] <Wellark> Saviq: landing-009 is mine
[15:06] <fginther> elopio, I doubt the test will be able to unlock the keyring itself (imagine this test running on any developers system).
[15:07] <fginther> elopio, I can look into disabling the lock on the system, but I think the test should account for this possibility and skip the test if the keyring is locked
[15:08] <sil2100> cjwatson: just a quick request - could you remove the prerequisite from the merge you requested? We might have a small bug in citrain that would mess up the changelog if we leave it like this
[15:08] <sil2100> cjwatson: link to the merge: https://code.launchpad.net/~cjwatson/address-book-app/arch-limits/+merge/218818
[15:08] <sil2100> cjwatson: I still need some time to fix this bug (and find what's causing this), but I need some free time for that
[15:09] <fginther> elopio, I may have found a way around this for jenkins, will test it
[15:09] <cjwatson> sil2100: OK, if you don't mind the diff being stupid as a result
[15:10] <cjwatson> Hm, I wonder if I can do that without resubmitting
[15:10] <cjwatson> Nope
[15:10] <sil2100> cjwatson: so maybe let me try submitting a merge with the same change
[15:10] <cjwatson> sil2100: I'll just resubmit, one moment
[15:10] <sil2100> Then I'll have more freedom hacking it up so that citrain will be ok with it
[15:11] <sil2100> And just mention that it's your change ;)
[15:11] <cjwatson> sil2100: https://code.launchpad.net/~cjwatson/address-book-app/arch-limits/+merge/218824
[15:11] <sil2100> Oh, thanks!
[15:11] <sil2100> :)
[15:11] <elopio> fginther: preferably, it will fail. Because if we can't add an account, we won't be able to test anything.
[15:11] <cjwatson> (and I've set a commit message now too)
[15:11] <sil2100> cjwatson: trying to feet it to citrain now, thanks again o/
[15:11] <elopio> fginther: do you know how to check if the keyring is locked?
[15:12] <fginther> elopio, it was just a suggestion. I have not yet come across a method to check if it is locked
[15:13] <dpm> Hi all, so I've installed image #17 using the dual boot app (as I usually do). The result is that I've got a completely blank dash - no scopes shown at all. Any ideas on how to debug that?
[15:14] <dpm> Actually, let me ask on -touch too
[15:25] <sil2100> uh oh
[15:26] <sil2100> cjwatson: heh ;) I have another favor to ask! I need to make CITrain happy... so, could you remove all changes from the debian/changelog? Like, remove all the entry for 0.2+14.10.20140507-0ubuntu1
[15:26] <sil2100> cjwatson: since right now citrain thinks 0.2+14.10.20140507-0ubuntu1 got released...
[15:27] <sil2100> cjwatson: if you won't have anything touching debian/changelog in your merge, then citrain will simply generate the changelog normally from scratch, which is what we want
[15:27] <cjwatson> err
[15:27] <cjwatson> would it be better for me to rebranch this from lp:address-book-app?
[15:27] <cjwatson> rather than from utopic-proposed
[15:27] <cjwatson> I feel pretty twitchy about removing a changelog entry
[15:28] <sil2100> cjwatson: yeah, that can be as well, utopic-proposed wasn't so bad because we at least were sure to be 'conflict proof' - but lp:address-book-app rebasing would be ok as well
[15:28] <sil2100> Sorry for disturbing...
[15:29] <cjwatson> sil2100: push --overwrite done
[15:29] <cjwatson> try that?
[15:30] <sil2100> That was fast!
[15:30] <sil2100> :)
[15:30] <sil2100> Let me try, thanks!
[15:37] <davmor2> sil2100: I've been testing tablets all day all I can say is the phone is better
[15:37] <sil2100> ;)
[15:37] <davmor2> sil2100: manta is particularly sucky
[15:38] <davmor2> pmcgowan: I'm going to write an email up for manta it has some quirks particular to it
[15:40] <pmcgowan> davmor2, ok
[15:41] <cjwatson> sil2100: Do I need to be concerned about the CI failure?  It's fairly obviously nothing to do with my branch
[15:42] <fginther> elopio, do you know what key that test is trying to access?
[15:44] <sil2100> cjwatson: ah, I think I need to force the build - since we'll be basically ignoring the -proposed version and 'replacing' it with this one
[15:44] <sil2100> cjwatson: so all is cool
[15:44] <elopio> fginther: I don't know. mardy?
[15:45] <cjwatson> ok
[15:45] <fginther> elopio, also, my first attempt to force the keyring to be unlocked failed. Any suggestions here? I tried adding giving the user full sudo permission, but that did not work
[15:47] <elopio> fginther: I'm going blind here :) I hit a wall, ask how to solve it, and try. But I have never tested online accounts before.
[15:48] <fginther> elopio, I understand. I'm in pretty much the same position. I don't know how to tweak the environment to make it work (or even if it's possible)
[15:50] <elopio> mardy will be able to tell us how or to point to somebody who knows. But it's probably too late for him.
[15:50] <elopio> dpm: do you know somebody else who can help us?
[15:52] <xnox> fginther: what's this for?
[15:53] <fginther> xnox, a test being added by elopio is adding a resource that requires access to the keyring. It appears that in the jenkins test infrastructure this is locked
[15:54] <fginther> while in elopio's development environment it is not
[15:54] <xnox> fginther: is that a unit test, or on the phone?
[15:54] <xnox> fginther: we may not have extended attributes for gnome-keyring to be functioning.
[15:54] <fginther> xnox, it's an autopilot test for a coreapp, one of the test targets would be a phone.
[15:54] <xnox> fginther: can you give me url to the failure?
[15:55] <fginther> in this case w're just trying to get it to run on a virtual desktop
[15:55] <dpm> elopio, not sure who other than mardy, perhaps dbarth can point you to someone else knowledgeable with online accounts on his team?
[15:55] <xnox> fginther: there is no keyrings on the phone yet.
[15:55] <xnox> fginther: as in ui to unlock it.
[15:55] <fginther> xnox, <IP_ADDRESS>:8080/job/generic-mediumtests-utopic/45/console
[15:55] <xnox> fginther: on the virtual desktop -> depends how you create/start the virtual destkop.
[15:55] <dpm> elopio, or mterry perhaps?
[15:56] <fginther> xnox, it's started with xinit
[15:56] <xnox> fginther: nah, that won't be enough.
[15:56] <fginther> lightdm is configured for auto-login (if it even matters in this case)
[15:57] <xnox> fginther: you need a full pam session + session dbus + autostart gnome keyring agents, all of which should be authenticated passwordless already. I don't see in the log, how xinit/desktop session has been started.
[15:57] <xnox> fginther: i only see pbuilderjenkins already.
[15:57] <xnox> fginther: where is that code?
[15:57] <fginther> one moment
[15:58] <xnox> fginther: i only see simple "startx" which will not be enough.
[15:59] <xnox> fginther: and lightdm is not autologged in, but explicitely stopped (thus all active / full pam sessions are killed)
[16:00] <fginther> xnox, here's the startx script http://paste.ubuntu.com/7416778/
[16:00] <xnox> fginther: either the tests should create a mock keyring, store things in it, and start it up unlocked -> or mock the calls to keyring with dummy/test data.
[16:00] <xnox> fginther: or e.g. check environment variables and skip the tests when full unlocked secrets service is not availalb.e
[16:01] <xnox> fginther: yeah, that's too minimal to get desktopy/normal dbus services running.
[16:03] <xnox> fginther: that's reminders app right? i bet i can break the test the same way on a regular desktop just by munging environment a little.
[16:04] <fginther> xnox, yes this is reminders. thanks for the input
[16:05] <fginther> xnox, do you know what environment variables to check, something that the test could use as a skip indicator?
[16:05] <dbarth> elopio: yes, sorry that really a mardy question
[16:06] <dbarth> elopio: please msg us to follow up tomorow; thanks
[16:07] <renato_> sil2100, about the address-book-app dependency problem, I was thinking about that, another solution is make the "qtdeclarative5-ubuntu-keyboard-extensions0.1" a different project, since this does not depend of any keyboard code
[16:07] <xnox> fginther: i believe it's GNOME_KEYRING_CONTROL
[16:07] <xnox> fginther: but i wanted to check/try that.
[16:08] <fginther> xnox, much thanks for your help
[16:09] <dbarth> o/ sil2100: we have a new landing request on line 32
[16:12] <sil2100> plars: meeting, but actually no new image, so no test image updates I guess ;)
[16:15] <popey> davmor2: https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1317579
[16:19] <davmor2> popey: why was it reduced?
[16:20] <plars> sil2100 I'm at a sprint today and probably tomorrow, just email if there's anything urgent
[16:20] <sil2100> plars: ah! Ok, thanks :)
[16:21] <ogra_> [16:21] <popey> dpm: ^^
[16:22] <davmor2> ogra_: I scoff at your 3 minutes out,  My flo was 17 minutes out
[16:22] <mardy> elopio, fginther: the test is trying to write something in the "login" keyring
[16:23] <sil2100> \o/
[16:23] <sil2100> ogra_: thank you!
[16:23] <ogra_> davmor2, heh, bad in any case
[16:23] <dpm> popey, \o/
[16:23] <dpm> thanks for the heads up
[16:23] <davmor2> ogra_: it then updated the time to be 10 minutes out, it then updated again to be the right time
[16:24] <ogra_> oh, never had that ... it is usually just behind wehn unlocking here and then updates within a few seconds
[16:24] <popey> dpm: if you have 5 mins I could do with some help with kits
[16:24] <fginther> mardy, thanks... with some help from xnox, it looks like the environment used on jenkins is far to minimal to support this kind of test. I'm adding some comments to the MP.
[16:24] <popey> dpm: maybe in the morning if thats better
[16:24] <sil2100> Damn, just noticed the changelog entry for ofono
[16:24] <mardy> elopio, fginther: I'm not very familiar with the gnome keyring myself, but maybe something like "echo p4ssw0rd | gnome-keyring-daemon -r -l" could work?
[16:24] <sil2100> It's so badly broken ;/
[16:25] <dpm> popey, I think I've finished my dogfooding, not much more I can do with Reminders, so I've got time if you like
[16:25] <mardy> fginther: would it be possible to uninstall signon-keyring-extension for this test? maybe by adding a Conflicts: line in the autopilot test package?
[16:25] <fginther> mardy, hmm
[16:26] <fginther> mardy, that doesn't sound too favorable to developers running the tests
[16:26] <popey> dpm: https://plus.google.com/hangouts/_/76cpi7i6pjou8uppscam2kh3rs?hl=en
[16:26] <fginther> but maybe we try something like that on jenkins
[16:28] <mardy> fginther, elopio: or modify /etc/signond.conf
[16:28] <sil2100> Ah, and I see why it's so broken
[16:28] <sil2100> Damn, why didn't we notice it earlier ;/
[16:28] <sil2100> ogra_: you think we should somehow fix the ofono changelog?
[16:29] <sil2100> ogra_: btw. how was the situation with the MMS support? Do we have every bits landed already?
[16:29] <ogra_> sil2100, awe_ said he will fix it retroactively with the next ofono upload
[16:29] <ogra_> sil2100, nuntium needs to move out of NEW
[16:29] <ogra_> (thats the mms handling daemon)
[16:30] <ogra_> not sure where that stands, slangasek and sergiusens were working on it last night
[16:30] <sil2100> Thanks ;)
[16:32] <fginther> mardy, set SecretsStorage=default ?
[16:32] <mardy> fginther: that should do it
[16:34] <mhr3> sil2100, sru verification of silo 019 failed, what to do?
[16:34] <mhr3> sil2100, can we drop it from proposed and free to silo?
[16:42] <bfiller> sil2100, robru: can I have a silo please for line 34 when you have a chance?
[16:42] <robru> bfiller, sure thing
[16:42] <sil2100> robru: ^ can you take that? :)
[16:42] <sil2100> mhr3: hmmm
[16:43] <sil2100> mhr3: yeah, I guess the way to go is asking someone with archive-admin power to drop the package and then force-freeing the silo, marking the landing as rejected
[16:43] <robru> bfiller, silo 16
[16:43] <sil2100> mhr3: I can do the second part, but the first part still needs some poking
[16:44] <bfiller> robru: cheers
[16:44] <robru> bfiller, you're welcome
[16:44] <mhr3> sil2100, well, fwiw it can stay in proposed, guys are working on a different fix, and the current version in -proposed mostly adds debug data, doesn't make the situation worse
[16:44] <mhr3> sil2100, but also doesn't fix the actual bug
[16:44] <robru> sil2100, not sure how much poking is necessary, once sru team sees "verification-failed" on the sru bug, won't they drop it from proposed themselves?
[16:44] <cjwatson> generally yes eventually
[16:45] <cjwatson> it's fine from our POV to leave it there for a while if somebody's working on fixing it
[16:45] <sil2100> mhr3: what silo was that?
[16:45] <sil2100> robru, cjwatson: ok, let's leave it for now anyway
[16:46] <mhr3> sil2100, so just force-free the silo?
[16:46] <sil2100> mhr3: yep, please prepare a different landing for the real fixes if you can :)
[16:46] <sil2100> This way we'll track status of landings better
[16:46] <mhr3> sil2100, leave the line though, i'll reuse it once it's ready again
[16:46] <sil2100> Oh, you want to reuse this one?
[16:46] <mhr3> i mean, i could
[16:46] <mhr3> if you tell me not to.. i won't
[16:47] <sil2100> Would be nice if there would be a new one, this way we have history
[16:47] <mhr3> fine
[16:47] <sil2100> Thanks
[16:59] <robru> mhr3, is line 9 really 'ready' or is the bot just confused because he silo was freed?
[16:59] <mhr3> robru, fixed
[16:59] <robru> thanks
[17:00] <robru> sil2100, are you still working on silo 4?
[17:00] <mhr3> can i get silo for 33?
[17:00] <sil2100> Ah, it built, let me confirm it and publish
[17:00] <sil2100> robru: yes
[17:00] <robru> sil2100, k, let me know when you EOD
[17:01] <robru> mhr3, silo 13
[17:02] <mhr3> eh
[17:02] <mhr3> i meant 29
[17:02] <mhr3> but well.. nevermind now
[17:20] <sil2100> robru: phew, ok, finished what I was doing, EODing now - landings are in your hands now o/
[17:20] <sil2100> Good luck
[17:20] <sil2100> ;)
[17:21] <robru> mhr3, oops sorry. didn't see your messages til just now. line 29 got silo 19
[17:21] <mhr3> thx
[17:24] <robru> you're welcome
[17:32] <renato_> robru, what is the status of the silo 004?
[17:32] <renato_> can we land that?
[17:33] <robru> renato_, yes, address-book-app is in -proposed.
[17:33] <robru> renato_, the rest has landed already. should be done soon
[17:33] <renato_> if it easy for you guys I can create a new project only for the new keyobard package that does not depend of the keyboard itself
[17:34] <renato_> robru, thanks
[17:34] <robru> renato_, don't thank me, sil2100 stayed past his EOD to make sure it got landed ;-)
[17:39] <bfiller> renato_, popey : qtorganizer5-eds is silo16 if you want to test it to fix the alarms bug https://launchpad.net/~ci-train-ppa-service/+archive/landing-016/
[17:47] <fginther> elopio, check out http://<IP_ADDRESS>:8080/job/generic-mediumtests-utopic/58/console
[17:48] <fginther> elopio, it looks like mardy's suggestion worked
[17:48] <fginther> elopio, can you verify the correct tests ran?
[17:51] <Saviq> Wellark, so you're aware that 005 is landing and you'll need to rebuild unity8 as soon as that's done?
[17:52] <elopio> fginther: yes!
[17:52] <Saviq> Wellark, i.e. now
[17:52] <elopio> that's nice. fginther: so are all the runners configured to workaround this keyring problem now?
[17:52] <elopio> we'll need to see if we can use this in other tests.
[17:53] <Saviq> plars, thanks, that worked great!
[17:53] <Saviq> plars, just one nitpick: in the default job config, ubuntu_filemanager_app should be replaced with filemanager
[17:53] <fginther> elopio, awesome. I still need to update the other host
[17:54] <plars> Saviq: I thought psivaa had already made that change. I'll check on it in a bit
[17:55] <Saviq> plars, thanks
[17:57] <psivaa> plars: Saviq: i made the change for the smoke tests. is this in relation to that or ci/ auto-landing jobs?
[17:57] <Saviq> psivaa, autopilot gatekeeper
[17:57] <Saviq> http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/
[17:58] <plars> Ah OK. That's different
[17:58] <plars> It'll need some extra help I guess
[17:58] <popey> bfiller: thanks
[17:59] <psivaa> plars: i see some config parameters in the above job saying ubuntu_file_manager. but that's ci-train bit and i have not done any yet on that :)
[18:10] <Wellark> Saviq: nope. but I am now
[18:10] <Wellark> thanks for the heads up
[18:10] <Saviq> Wellark, not sure who you paid off to get a silo for unity8 when there was one already ;)
[18:11] <Wellark> Saviq: well, I need to sync the landing of indicator-network and the relevant unity8 MP
[18:11] <Wellark> as they are tightly coupled
[18:12] <Wellark> Saviq: please don't tell me that this stuff does not scale for same component in multiple silos..
[18:12] <Saviq> Wellark, nope, it doesn't
[18:13] <Saviq> Wellark, you can only have one component in a single silo (which makes perfect sense, btw)
[18:13] <Saviq> Wellark, I think you mistook the train for a testing ground
[18:14] <Wellark> lalalalalalalalalala
[18:15] <Wellark> Saviq: nope it does not make sense as it does not scale for multiple people working on different parts of the code base and other components with interdependencies
[18:15] <Wellark> please, don't reply
[18:15] <Wellark> lalalalala
[18:16] <balloons> popey, I pushed those fixes to calendar I wanted to make. I notice most of the tests pass on my device, so it's much better now than everything failing as you saw
[18:19] <dobey> robru, cyphermox, rsalveti: can we get a rebuild of unity-scope-click in silo 013 please?
[18:24] <rsalveti> dobey: done
[18:25] <dobey> thanks
[18:26] <Saviq> Wellark, it does make sense in that you can't test something that's moving under your feet
[18:26] <Saviq> Wellark, so having a single component in multiple silos just means you'll need to rebuild them all whenever any of them lands and retest
[18:27] <Wellark> Saviq: that's because the packages from a silo are copied directly to  proposed?
[18:28] <Wellark> thus making packages in other silos outdated / clashing with the -propose one
[18:29] <Saviq> Wellark, what does that matter? how can you test something and say it's ready to land if there's something landing in trunk before what you're testing?
[18:31] <Wellark> don't fully understand the point you are trying to make..
[18:31] <Wellark> unity8 for example is big enough code base
[18:32] <Wellark> that there can be multiple changes done to the code base that are not affecting each other
[18:32] <Wellark> and can be merged and tested separately from each other
[18:34] <Wellark> and to make sure there is no unnoticed breakage between the separate merges we have an extensive autopilot test suite which we should be running at multiple stages
[19:11] <bzoltan> rsalveti: robru: cyphermox: I just turned the Silo12 tested as all the key apps give green and all the failures are the same as on the dashboard or without the SIlo. It is good to go for me
[19:11] <robru> bzoltan, great thanks
[19:12] <bzoltan> robru:  I guess we need a QA chap to sign it
[19:12] <robru> bzoltan, yes, at this hour that should be ToyKeeper ^^
[19:13] <bzoltan> robru: ToyKeeper: I would appreciate  :) I go EOD and will look the logs and stuff in 6 hours or so
[19:13] <robru> bzoltan, no worries.
[19:13]  * ToyKeeper -> scrollback
[19:15] <robru> ToyKeeper, only a couple of lines of scrollback ;-)
[19:17] <ToyKeeper> Ah, okay.  I was trying to figure out why it needs sign-off.
[19:19] <ToyKeeper> bzoltan: Row 25?  Looks like it didn't build correctly.
[19:19] <robru> ToyKeeper, hummm, not sure. I guess there's new features or something? it's marked as needing QA signoff in the spreadsheet
[19:19] <robru> ToyKeeper,  hmm? row 25 looks good here... row 23 says build failed
[19:20] <ToyKeeper> I may have the wrong spreadsheet, or an out-of-date-link.  This says the last image built was #5, even after reloading.  :(
[19:21] <ToyKeeper> robru: What's the correct link?
[19:23] <robru> ToyKeeper, oh yeah, we changed spreadsheets recently because google borked that one. hang on
[19:23] <robru> ToyKeeper, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc#gid=0
[19:30] <ToyKeeper> bzoltan: This has a test plan, but it appears to be just "all AP tests pass".  Got anything more specific, more related to the changes made?
[19:53] <robru> bbl, lunch
[20:41] <josharenson> Hey robotfuel, wondering if there was any update re: performance testing dashboard? Can I be of any help?
[20:42] <robotfuel> josharenson: cgoldberg and nuclearbob is doing that
[21:36] <dobey> robru, cyphermox, rsalveti: unity-scope-click from silo 013 passes the test plan for me. can one of you flag it as passing and twiddle whatever bits so it lands? thanks!
[22:02] <robru> dobey, on it
[22:03] <dobey> thanks robru
[22:03] <robru> dobey, you're welcome
[22:56] <robru> ToyKeeper, hey, just checking in. did you get a chance to look at silo 12?
[22:57] <ToyKeeper> robru: Yes, I've been running the tests and scratching my head at some of the results and trying to figure out what's related to the changes and what's not, and ...  sigh.  Lots of changes bundled together.
[22:57] <ToyKeeper> It'd really help if it had an actual test plan, including what changed and how to test it.
[22:57] <robru> ToyKeeper, yeah, it seems to be a big code-dump :-(
[22:58] <ToyKeeper> Do you know why this one required QA attention?
[22:58] <robru> ToyKeeper, the MP has bug references, but I've not looked at them to see what quality they are: https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/landing_080514/+merge/218775
[22:58] <robru> ToyKeeper, no I don't...
[22:58] <ToyKeeper> Yeah, I've been using the MP to get details.
[22:58] <robru> right
[22:59] <robru> ToyKeeper, bzoltan did say that all the failures were reproducible without this branch (eg, so the branch doesn't introduce any new regressions). I guess if you confirmed that I'd be happy, not really sure what to make of it myself
[23:00] <ToyKeeper> Yeah, it'd be nice if he had left a log of the AP test results to compare against.
[23:00] <ToyKeeper> About all I can say is that I *think* I'm getting the same results, which means it should be landable.  The test plan needs work though.
[23:04] <robru> ToyKeeper, alright, I'll publish it then. thanks.
[23:08] <ToyKeeper> robru: I did notice a minor bug; the brand new secondary text cursor is off by a few letters in the weather app.
[23:08] <robru> secondary text cursor?
[23:09] <ToyKeeper> I don't know why it was added.  http://toykeeper.net/tmp/secondary-text-cursor.png
[23:11] <ToyKeeper> http://toykeeper.net/tmp/secondary-text-cursor-misaligned.png
[23:11] <ToyKeeper> Er, wrong url.
[23:11] <ToyKeeper> http://toykeeper.net/tmp/secondary-text-cursor-weather.png
[23:12] <robru> ToyKeeper, lol, that does look funny. and it's only in weather app? no other text box gets that?
[23:12] <ToyKeeper> Not exactly a regression, since it never existed before...  but a little weird.
[23:13] <ToyKeeper> All text boxes get it, but it only seems misaligned when there's an icon at the left side of the text box.
[23:13] <robru> ahhhhhh
[23:13] <robru> ToyKeeper, well it's up to you if you want to block on that.
[23:22] <ToyKeeper> It's such a minor thing I don't think it's worth blocking.
[23:23] <ToyKeeper> ... I generally care a lot more about functional issues than visual glitches.