[00:41] <xnox> thomi: where is the branch for python-autopilot?
[00:44] <xnox> or barry ^
[00:57] <xnox> slangasek: thomi: barry: I've sent 2 merge proposals & requested review from all of you: python3-autopilot => pull in everything for qt/pyhon3 tests. python-autopilot => pull in everything for qt/python2 tests.
[00:57] <xnox> if Gtk/X testing is required, add autopilot-desktop in addition to python3?-autopilot dep.
[00:58] <xnox> no need to have 2 packages that can't do anything on their own & 4 meta-packages to make the first two working. We can simply pick a default, make the headline packages useful by default for the common case + provide 1 addon metapackage to pull in extra/big dependencies (gtk/x)
[02:04] <imgbot> [02:16] <thomi> xnox: hey, I'm back now - that took longer than I expected :(
[03:24] <thomi> robru: cyphermox: either of you two still at work?
[03:24] <thomi> ... or any other debian packaging gurus?
[03:25] <robru> thomi, hey, what's up?
[03:25] <thomi> hi robru
[03:25] <thomi> robru: barry and I are trying to fix a FTBFS on the launchpad builders. He's been doing most of the work, I've been submitting the branches... We finally got a branch that builds in a PPA, but ci fails with:
[03:26] <thomi> https://jenkins.qa.ubuntu.com/job/autopilot-autopilot-temp-dev-trusty-amd64-ci/26/console
[03:26] <thomi> which looks like dh_sphinxdoc isn't installed
[03:26] <thomi> so I added sphinx-common to the build-deps
[03:26] <thomi> but it looks like the build deps aren't being installed!?
[03:26] <thomi> so now I'm really confused O.0
[03:27] <thomi> even more confused as to how/why it works on the launchpad builders I guess
[03:28] <robru> thomi, that log you linked, is that before or after you added sphinx-common?
[03:28] <thomi> robru: after
[03:28] <thomi> if you search for sphinx-common you can see it in there
[03:29] <thomi> the MP is https://code.launchpad.net/~thomir/autopilot/temp-dev-FTBFS/+merge/217987 BTW
[03:29] <thomi> you can see sphinx-common was added at revno 495
[03:29] <imgbot> [03:29] <imgbot> [03:32] <robru> thomi, hum, that is really strange, I installed sphinx-common and confirmed that it installs to the right place, under /usr/share/perl5 which is part of @INC
[03:32] <thomi> yeah
[03:32] <thomi> robru: and this builds fine for me locally
[03:32] <thomi> and, like i say, in the lp builders :-(
[03:32] <robru> thomi, are you on trusty?
[03:33] <thomi> robru: I'm on both trusty and utopic
[03:33] <thomi> I haven't tried building under utopic though, I'll try that
[03:33] <robru> thomi, you mean it builds in a PPA? because if it builds in a PPA, it'll build in a silo, and having it work in a silo is IMHO more important than the jenkins ci bot that runs individual MPs.
[03:34] <thomi> robru: yeah, it builds in a PPA
[03:34] <robru> thomi, other than that error, do you think this branch is ready for release?
[03:34] <thomi> robru: yeah, but if we can't get it to work then it means we can't have CI any more :(
[03:34] <robru> hmmm
[03:34] <thomi> robru: well, this is just merging to our temp-dev branch
[03:34] <thomi> so... not ci-train release, no
[03:34] <thomi> but.. ready for landing into our dev branch, sure
[03:35] <robru> oh hm
[03:35] <robru> thomi, well I was going to say "let's just put this in a silo and steamroll over ci jenkins objections..." but that's only if you're ready for real release
[03:35] <thomi> robru: well, but again that means breaking CI
[03:36] <thomi> which is fine for this branchm, but I assume it'll break for all future branches as well, until we find & fix the problem
[03:36] <robru> yeah, that's really strange
[03:36] <robru> thomi, this might be more of an fginther issue, he knows more about the ci side (I focus mostly on the train side)
[03:37] <thomi> ok, thanks. I think he's EOD'd
[03:37] <thomi> speaking of, isn't it crazy-late for you too?
[03:37] <robru> yeah i think so. i did too but you got lucky ;-)
[03:37] <thomi> ahhh
[03:37] <robru> almost 9PM here
[03:37] <thomi> yeah... why are you still at work? I mean, I appreciate it but...
[03:38] <robru> thomi, oh, I was waiting for image #8 to finish building so I could send out a landing team email about it and then sign off ;-)
[03:38] <robru> thomi, but yeah, I really don't understand that log. one thing that caught my eye is that it doesn't seem to log actually installing any of those packages. it just says that those dependencies are unmet a few times.
[03:39] <thomi> yeah
[03:39] <jamesh> so is there any particular process we need to go through to get CI jobs switched to run on utopic instead of trusty?
[03:39] <robru> jamesh, probably fginther is the guy to do that
[03:39] <robru> thomi, jamesh : you guys should both email him for tomorrow ;-)
[03:40] <jamesh> will do.
[03:58] <bzoltan1> robru: still around?
[03:59] <robru> bzoltan1, maybe ;-)
[03:59] <robru> bzoltan1, what's up?
[03:59] <bzoltan1> robru: Hehe :)
[03:59] <bzoltan1> robru: I need info about the landing policy ...
[03:59] <robru> bzoltan1, what did you need to know?
[03:59] <bzoltan1> robru: I am in the silo9 and the powerpc builds are flaky
[04:00] <robru> oh yeah
[04:00] <bzoltan1> robru:  powerpc is hardly a target and we can not even test on it ...
[04:00] <bzoltan1> robru: Would it be possible to stop building the UITK on powerpc?
[04:01] <robru> bzoltan1, i see your point, but that's not my call... if it used to build on powerpc but no longer does, -proposed will consider it a regression and prevent it from landing. So you'd have to discuss that with the release team, infinity or cjwatson
[04:01] <bzoltan1> robru: Here is the log https://launchpadlibrarian.net/174336910/buildlog_ubuntu-utopic-powerpc.ubuntu-ui-toolkit_0.1.46%2B14.10.20140501.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[04:05] <bzoltan1> robru: OK, I will talk to them. It is a bit annoying... i would not say "it used to build", because the powerpc builds are flaky for some time already... if I push rebuild enough it will build.
[04:05] <robru> bzoltan1, hmm, yeah, I don't care about powerpc personally but like i said it's not my call.
[04:06] <robru> alright, I'm off! goodnight everybody!
[04:06] <bzoltan1> robru: OK, no worries.. I will talk to the guys
[04:06] <bzoltan1> robru: good night
[04:07] <bzoltan1> robru: I can tell you by looking to my window that Friday will be a sunny day :D
[04:19] <Mirv> bzoltan1: it will rain all day, though ;)
[04:54] <bzoltan1> Mirv:  had to believe
[06:22] <didrocks> Mirv: can you try the mediaplayer AP test yourself?
[06:22] <didrocks> just to ensure it's due to media hub
[06:25] <Mirv> ok
[06:39] <bzoltan1> didrocks: I wish to disable the powerpc builds for all sdk projects.. starting with the UITK
[06:40] <didrocks> bzoltan1: it's something you need to discuss with the release team
[06:40] <bzoltan1> didrocks: it is pure waste of time to strugle with powerpc, the tests are flaky on powerpc, the builds are unreliable
[06:40] <didrocks> bzoltan1: I doubt it will accepted though
[06:40] <didrocks> bzoltan1: you can disable the tests at worst on powerpc
[06:40] <bzoltan1> didrocks: wasting time and money
[06:40] <didrocks> bzoltan1: don't argue about it with me, I have no power on that :)
[06:41] <bzoltan1> didrocks: I am not arguing :) I am stating ...
[06:41] <bzoltan1> didrocks: how to disable tests for and arch?
[06:41] <didrocks> bzoltan1: in debian/rules, you need to compare the archs and override dh_auto_tests for that arch
[06:41] <didrocks> I guess Mirv can do it
[06:41] <didrocks> and give you an example :)
[06:42] <bzoltan1> didrocks: that sounds good, thanks
[06:42] <Mirv> bzoltan1: http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src/revision/157
[06:42] <bzoltan1> Mirv: OK.. I take a look at it
[06:47] <didrocks> Mirv: bzoltan1: you should rather do the contrary
[06:47] <didrocks> list the arch you disable them on
[06:48] <didrocks> Mirv: mind doing that on qtbase-opensource-src?
[06:48] <didrocks> I think we want the tests running on arm64
[06:48] <didrocks> for instance
[06:59] <didrocks> Mirv: FYI, I'm disabling the backend sync for now
[06:59] <didrocks> Mirv: just to see if the spreadsheet will calm down
[06:59] <didrocks> with less requests
[06:59] <Mirv> ok, I need to look at that. right now I fail to remember if they did fail also there or not, and for some reason I don't remember I don't find the build logs for that upload that would tell it
[07:00] <didrocks> thanks
[07:05] <didrocks> Mirv: anyway, it seems the spreadsheet has been rolled back 2 days ago for me
[07:05] <didrocks> Mirv: is it the same for you?
[07:05] <didrocks> like usensord isn't landed?
[07:10] <Mirv> didrocks: usensord looks landed to me?
[07:10] <Mirv> I mean, on the spreadsheet too
[07:10] <didrocks> Mirv: can you copy the spreadsheet to a backup?
[07:10] <didrocks> it's not for me
[07:10] <didrocks> so, maybe your version is more fresh than mine
[07:10] <didrocks> Mirv: just file -> make a copy
[07:10] <didrocks> and call it backup1 :)
[07:14] <didrocks> Mirv: do you have the link of your backup? I want to compare with the view of reality I'm seeing
[07:15] <Mirv> didrocks: I made a backup. unfortunately the backup is now also reverted.
[07:15] <didrocks> urgh?
[07:15] <Mirv> as is the normal one for me too :(
[07:15] <didrocks> wth!
[07:15] <didrocks> there is clearly some magic…
[07:16] <didrocks> well, once the spreadsheet will be a better shape, we'll reconciliate I guess
[07:16] <didrocks> in a*
[07:16] <didrocks> with the reality
[07:17] <Mirv> urgh indeed
[07:18] <Mirv> didrocks: what I did see is that the Revision history seems to have been stuck at the same point on Apr 30 in any case, no matter how many changes or landings after that.
[07:18] <didrocks> Mirv: indeed
[07:18] <Mirv> so it feels like it's permanently stuck there, and then resets every now and then to that point
[07:18] <didrocks> seeing exactly the same
[07:19] <didrocks> Mirv: well, the weird thing is that the image build number is from today
[07:19] <didrocks> I disabled both cronjob to update that and the status
[07:19] <didrocks> ah, let's try something
[07:20] <didrocks> I'm locking down the spreadsheet
[07:20] <didrocks> to only me
[07:20] <didrocks> (for the pending one
[07:20] <didrocks> that:
[07:20] <didrocks> - will force people to ask us about it
[07:20] <didrocks> if they don't read robru's email
[07:20] <didrocks> - we will see then if the spreadsheet stabilize without any writings…
[07:42] <ToyKeeper> Well, that explains why I can't see the spreadsheet.
[07:43] <didrocks> yep :)
[07:43] <didrocks> well, you should see it still
[07:43] <didrocks> just not edit
[07:44] <didrocks> (I can clearly see it in an anonymous account here)
[07:47] <ToyKeeper> Oh, actually...  it seems that the sheet I can't access is something else.  Not sure what.  I can still see the landing one though.
[07:47] <ToyKeeper> Given its placement in my tab hierarchy...  I'm guessing it's the malta sprint attendance sheet.
[08:20] <ogra_> didrocks, hmm, did you actually want to have a meeting ?
[08:21] <didrocks> ogra_: why not? we did get a new image, right?
[08:21]  * ogra_ thought we'd skip due to lack of people
[08:21] <didrocks> only sil2100 is missing
[08:21] <ogra_> more than one, yes
[08:21] <ogra_> ah k
[08:26] <tsdgeos> guys, any idea with what's wrong with https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/469/console ?
[08:30] <Mirv_> Mirv: are you going to time out?
[08:31] <Laney> can't you ghost/release it?
[08:31] <didrocks> ogra_: coming?
[08:32] <Mirv> ha! thanks Laney.
[08:33] <Mirv> I don't think I've ever used that command before
[08:33] <ogra_>  if google lets me
[08:34] <Laney> ph33r the nickserv
[09:05] <dbarth> hey
[09:06] <davmor2> Morning all
[09:06] <dbarth> so did you guys figure out the spreadsheet instability?
[09:06] <dbarth> just looking to have a new silo ;)
[09:09] <Mirv> dbarth: no, the sheet seems resetting to Apr 30th state every now and then.
[09:09] <Mirv> even when it seemed to work, it claimed there were no later changes after that certain point in the Apr 30 evening
[09:17] <didrocks> dbarth: we can still assign silos manually though if needed
[09:18] <didrocks> Mirv: just propose that, and tell peoople to use http://people.canonical.com/~rbpark/citrain/ for tracking
[09:20] <didrocks> Mirv: I can build a rescue job for assigning everything manually as in the past if needed, wdyt?
[09:23] <Mirv> didrocks: I think an old-style preparing manually sounds good
[09:23] <didrocks> Mirv: ok, let me cook that!
[09:46] <didrocks> Mirv: ok, I tried both configuring and reconfiguring an existing silo
[09:47] <didrocks> Mirv: so, all works from https://ci-train.ubuntu.com/job/prepare-silo-manual
[09:48] <dbarth> didrocks: here is the silo request: http://pastebin.ubuntu.com/7378542/
[09:48] <didrocks> and ignoring conflict works
[09:49]  * didrocks now frees silo 16 & 17
[09:49] <didrocks> dbarth: you have branches and not merge requests
[09:50] <dbarth> oops
[09:51] <dbarth> didrocks: http://pastebin.ubuntu.com/7378551/
[09:51] <Mirv> didrocks: ok! good to have that fallback for now.
[09:51] <didrocks> Mirv: I'll assign that one FYI ^
[09:52] <didrocks> dbarth: landing-018 for you
[09:52] <didrocks> dbarth: direct links for the job will be available at http://people.canonical.com/~rbpark/citrain/ (or directly on jenkins)
[09:53] <dbarth> ok nic
[09:53] <dbarth> e
[09:53] <Mirv> ok
[09:54] <dbarth> Mirv: i'm also trying to get some webbrowse-app SRU out the door (line 36)
[09:54] <dbarth> to make room for olivier
[09:55] <dbarth> i pinged the rlease team, but maybe you can help?
[09:55] <dbarth> i can ensure some quick verification-needed/done cycle once i'm out of unapproved
[09:57] <Mirv> dbarth: I don't think there's anything else that can be done besides pinging to get it out of unaproved
[09:58] <Mirv> dbarth: so another SRU still after that one?
[09:59] <dbarth> Mirv: ok
[09:59] <dbarth> Mirv: and yes, there will be one more
[09:59] <dbarth> (plus the seies of unity-webapps-* fixes in the other line)
[10:29] <dbarth> didrocks: one my landings has a bad changelog (misses a bug ref. which was attached to another branch, anyway)
[10:30] <dbarth> didrocks: question: do i need to go CI again, or could i update my MP with the changelog change?
[10:30] <dbarth> i'm tyring to see what's simpler / safest
[10:30] <didrocks> dbarth: you update the MP with the changelog change, rebuild only that component (with REBUILD_PACKAGES = "source package name") and get that republished
[10:31] <didrocks> dbarth: if you didn't change the changelog in that MP, just attaching to the bug to the MP is enough
[10:31] <dbarth> didrocks: ok
[10:31] <didrocks> dbarth: with the same partial rebuild trick
[10:31] <dbarth> ok,trying that now
[10:40] <bzoltan> Mirv: didrocks: the silo9 is ready to land, all tests are green
[10:42] <mhr3> spreadsheet still broken, or can i add new landing asks?
[10:43] <didrocks> bzoltan: no ack on silo9 landing
[10:43] <didrocks> bzoltan: new build-deps in universe
[10:44] <bzoltan> didrocks: What is that new build-deps?
[10:44] <didrocks> mhr3: still broken, but if you pastebin your request, we can assign silos manually
[10:44] <didrocks> bzoltan: python3-flake8
[10:44] <didrocks> https://ci-train.ubuntu.com/job/landing-009-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_0.1.46+14.10.20140502.3-0ubuntu1.diff
[10:45] <didrocks> bzoltan: the changelog is weird, seems you even didn't get it mention in the commit
[10:45] <bzoltan> didrocks: let me find the chap who made that...
[10:46] <didrocks> bzoltan: you bundle multiple commits in one MP it seems
[10:46] <didrocks> bzoltan: you would need to file the changelog manually to get it correct
[10:46] <dednick> fginther: hi. seems there doesnt seem to be CI on ubuntu-settings-components anymore. Any idea?
[10:46] <didrocks> bzoltan: so changelog will need fixing as well
[10:47] <bzoltan> didrocks:  yes, we use a staging branch of the UITK for some time now
[10:47] <didrocks> bzoltan: so, please file up the changelog manually
[10:48] <didrocks> bzoltan: or the generated one will be messed up
[10:48] <didrocks> or ensure the commit message contains everything
[10:48] <bzoltan> didrocks: I rather fill up the changelog ...
[10:49] <bzoltan> didrocks: other than the changelog ... what is the problem with the new build-dep?
[10:49] <didrocks> bzoltan: it's in universe
[10:49] <davmor2> didrocks: media-player looks like it locks up if you pause it and try to close it, but it doesn't actually close the app would be why the tests are failing maybe?
[10:49] <bzoltan> didrocks: is it a problem I should/could solve?
[10:49] <didrocks> bzoltan: you should solve for sure
[10:50] <didrocks> solve*
[10:50] <dednick> fginther: ok, so ci seem to be there, but not autolanding
[10:50] <bzoltan> didrocks: no idea how
[10:50] <psivaa> didrocks: ogra_: so the reason for manta showing less number of tests is because it goes 'device not found' during a few tests. unity8 is seeing this the most
[10:50] <didrocks> bzoltan: you need to either to a MIR
[10:50] <didrocks> bzoltan: to get the build-deps in main
[10:50] <didrocks> or remove it from the build-deps list
[10:50] <didrocks> until then, publication is blocked
[10:50] <bzoltan> didrocks: OK
[10:51] <didrocks> bzoltan: the MIR needs to be approved, which can take some weeks
[10:51] <didrocks> days if you push a little bit :)
[10:52] <didrocks> davmor2: interesting…
[10:52] <t1mp> bzoltan: let's not wait that long... but remove the build-dep for now?
[10:52] <Mirv> davmor2: yeah it seemed something is funny with the media player even though it plays back videos.
[10:52] <bzoltan> t1mp: I do not know why elopio mad that
[10:53] <dbarth> the silo rbuild worked perfectly
[10:53] <dbarth> just sayin
[10:53] <didrocks> t1mp: bzoltan: next time you add a dep, please check if it's in main or universe first, before the landing
[10:53] <didrocks> or just kick out the MP which change the dep?
[10:53] <bzoltan> didrocks: OK
[10:53] <didrocks> ah no, you can't… you are using another trunk
[10:54] <bzoltan> didrocks:  packaging MRs should be reviewed by Mirv or by me... it was overlooked... I revert that MR
[10:54] <didrocks> great
[10:55] <Mirv> cool
[11:02] <popey> Mirv: when you get 5 mins could you please push filemanager click 0.3.169 to the store. I have run all ap tests. http://s-jenkins:8080/job/filemanager-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.filemanager_0.3.169_armhf.click
[11:02] <Mirv> popey: sure
[11:03] <popey> thanks
[11:05] <Mirv> popey: done https://myapps.developer.ubuntu.com/dev/click-apps/159/
[11:05] <popey> thank you
[11:05] <Mirv> shorts 218 or newer could be nice to have too, since it should fix the tests
[11:07] <popey> doing now
[11:08] <didrocks> Mirv: going for a run, in case mhr3 replies on day with a landing, I will let you handling it :)
[11:09] <mhr3> didrocks, oh yea, thx btw, preparing more branch ;)
[11:09] <didrocks> mhr3: we have an emergency job I've done today for that
[11:09] <didrocks> mhr3: and you have http://people.canonical.com/~rbpark/citrain/ for checking the backend status while the spreadsheet is disabled
[11:10] <didrocks> (and links to the jobs)
[11:10] <mhr3> didrocks, yea, robru's web is awesome
[11:10] <popey> Mirv: am having to bump the sdk framework version because some of the apps are still on 13.10 - bug 1315318 is tracking it.
[11:10] <mhr3> we should just have been using that :)
[11:10] <didrocks> mhr3: it doesn't have inline/collaborative editing
[11:10] <didrocks> database
[11:10] <mhr3> didrocks, details :P
[11:10] <didrocks> or even archiving/free text :p
[11:10] <didrocks> ahah
[11:10] <didrocks> and login/sso permissions
[11:11] <didrocks> mhr3: so, the only thing you won't be able to do is reconfiguring yourself
[11:11] <didrocks> be sure to put all MPs
[11:11] <didrocks> or you have to ask us for reconfiguring :p
[11:11] <mhr3> k
[11:12] <Mirv> popey: aha, that's nice. I'm wondering whether the OpenGL webapp games could see a framework bump to switch to oxide? folks would like to get QtWebKit 5.2 back in, and the only downside we had with that vs 5.1 were the OpenGL web site regressions
[11:13] <popey> well everything is going to have to go 14.04
[11:13] <popey> because nothing can go in the store if it's 13.10
[11:13] <Mirv> ah, ok, so it will happen eventually
[11:13] <popey> we also need to have *that* discussion about when 14.10 framework comes along - lool ?
[11:14] <popey> because music is soon going to make changes which will not work on 14.04
[11:25] <ogra_> also if we want turn -dev1 into proper -dev
[11:25] <ogra_> afaik -dev1 was only supposed to be used while the 14.04 framework isnt 100% finished
[11:38] <popey> indeed.
[11:45] <popey> Mirv: could you please do the same for reminders http://s-jenkins:8080/job/reminders-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.reminders_0.5.110_armhf.click
[11:49] <lool> popey: yes; so basically as soon as there's a new API/ABI that we want apps to be able to use, we should introduce a 14.10-dev1
[11:55] <Mirv> popey: done
[12:06] <popey> Mirv: thanks
[12:34] <popey> ogra_: where do bugs in adb on the device go?
[12:34] <popey> e.g. bug 1290435
[12:34] <mhr3> Mirv, so, can i get a silo with
[12:34] <ogra_> popey, android or android-tools depends what kind of bug
[12:34] <mhr3> https://code.launchpad.net/~unity-team/unity-scopes-api/staging/+merge/218063 https://code.launchpad.net/~unity-api-team/unity-scopes-shell/fix-tests-after-click-support/+merge/217480 https://code.launchpad.net/~mhr3/unity-scopes-shell/fix-1314702/+merge/217795 https://code.launchpad.net/~mhr3/unity-scopes-shell/test-reorg/+merge/218055
[12:35] <mhr3> Mirv, that ^?
[12:35] <mhr3> Mirv, it's just some minor bugfixes
[12:35] <popey> ogra_: that bug, confirmed my flo thinks its mako
[12:35] <ogra_> popey, hmm, thats a duplicate of one that pmcgowan filed recently ... i cant find it though :P
[12:36] <popey> i filed it too
[12:36] <popey> in the sdk.
[12:36] <Mirv> mhr3: okie
[12:36] <ogra_> all devices as mko :)
[12:36] <ogra_> *are
[12:36] <ogra_> thats hardcoded in adbd ... not easy to fix
[12:37] <pmcgowan> I thought we fixed that
[12:37] <ogra_> no, its not an easy fix
[12:37] <ogra_> i can fix it but we will lose all debugging functionality
[12:37] <Mirv> mhr3: landing-016
[12:38] <ogra_> and adbd would only work if nothing is broken (i.e. no adb in initrd or when the container fails to start anymore)
[12:38] <pmcgowan> wonder if I closed that incorrectly
[12:38] <popey> ok, moved bug 1290435
[12:39] <ogra_> i have no idea why QTCreator relies on that info though ... it should read the property instead like everything else does
[12:39] <mhr3> Mirv, ty
[12:39] <pmcgowan> ogra_, looks like qtc was fixed
[12:39] <ogra_> ah
[12:40] <ogra_> so the reporter uses an old version ?
[12:40] <popey> pmcgowan: after mpt filed bug 1313651 I have being going through those bugs again.. seems there's still some outstanding in the wrong place
[12:40] <ogra_> (teh bug against adbd shouldnt be closed though ... )
[12:41] <pmcgowan> right, the other one is closed https://bugs.launchpad.net/qtcreator-plugin-ubuntu/+bug/1297989
[12:41] <pmcgowan> he filed the bug just before the fix
[12:42] <ogra_> well, the adbd one is still valid
[12:42] <pmcgowan> yep
[12:42] <ogra_> and we need some way to switch between hardcoding and properties ... but that will be a non trivial change
[12:43] <ogra_> but i see QTC now uses libusb info ... thats good :)
[12:58] <didrocks> ogra_: thanks for the free shower btw, but… I didn't order it!
[12:58] <didrocks> :)
[13:00] <didrocks> and sure… blue sky now
[13:00]  * didrocks shakes a fist at clouds
[13:01] <ogra_> hey !
[13:01] <ogra_> we make money with clouds ... dont curse them :P
[13:02] <didrocks> ;)
[13:15] <plars> ogra_: we have several devices in the lab with some strange problems. It started out looking like two different things but looks to be the same now. got a sec?
[13:15] <ogra_> sure
[13:16] <didrocks> maybe linked to the WLAN connection issue?
[13:16] <ogra_> i saw your ping in the backlog already
[13:16] <ogra_> that shouldnt affect adb
[13:16] <plars> ogra_: I have a device that I was trying to flash with u-d-f, and it would seem to complete according to the recovery.log, but it never rebooted after
[13:16] <didrocks> oh right, stupid me :)
[13:16] <plars> ogra_: I tried trusty, utopic, stable... didn't matter
[13:16] <ogra_> and oyu used --bootstrap ?
[13:17] <ogra_> so that recovery gets flashed too
[13:17] <plars> ogra_: then fginther showed me that he had 3 devices (all running the latest trusty image) that he couldn't even boot to fastboot
[13:17] <plars> ogra_: yes, I did use --bootstrap
[13:17] <ogra_> hmm, weird ...
[13:17] <plars> ogra_: so just to start over completely, I had rfowler_ take mine, and one of fginther's and reflash with android, re-unlock, and reflash a touch image on them
[13:18] <ogra_> the only idea i have would be a kernel level bug ... adb reboot/reboot recovery/reboot fastboot all just directly call a kernel function
[13:18] <plars> ogra_: he was able to get the touch image on there I guess, but maybe not competely... it gets an oom whenever we try to install now, and some strange errors at the end of the log
[13:18] <ogra_> ugh
[13:18] <plars> https://pastebin.canonical.com/109485/
[13:19] <plars> E:Error in select (Bad file number)
[13:19] <plars> and the oom:
[13:19] <plars> https://pastebin.canonical.com/109484/
[13:19] <plars> ogra_: so I'm worried that all of these devices are just fried now, but strange for them to all happen in such a short timeframe
[13:20] <plars> because I was thinking that starting completely fresh should resolve whatever was going on, right?
[13:20] <ogra_> theoretically ...
[13:20] <ogra_> i wonder if the flash is worn out
[13:21] <ogra_> reflashing 100 times a day can surely hit wearl levelling
[13:21] <ogra_> *wear
[13:21] <plars> we don't flash 100 times per day for sure
[13:21] <plars> maybe up to 5 times or so
[13:21] <plars> usually more like 1 or 2
[13:25] <ogra_> could you try with an older u-d-f ?
[13:25] <ogra_> moght be thet formatting the partitions goes wrong or so
[13:25] <plars> hmm
[13:26] <plars> ogra_: you mean an old image? or an old version of udf?
[13:26] <ogra_> old version of udf
[13:26] <plars> ogra_: also, if that's the case wouldn't we see problems with all the devices?
[13:26] <ogra_> probably
[13:27] <Saviq> didrocks, hey, I'd like to SRU the fix for https://bugs.launchpad.net/unity8/+bug/1304548, have an MP set up and the bug description updated
[13:27] <Saviq> didrocks, can you do the nomination for me?
[13:28] <didrocks> Saviq: just name it and I'll approve the nomination
[13:28] <didrocks> nominate*
[13:28] <Saviq> didrocks, also, shall I be verifying the fix against -proposed, or just -updates?
[13:28] <Saviq> didrocks, how do I nominate?
[13:28] <ogra_> plars, i just see that udf formats flash ... and your error message in the paste kind of indicates a filesystem issue
[13:28] <didrocks> Saviq: oh, it's the split common package?
[13:28] <ogra_> well, formats /cache
[13:28] <didrocks> Saviq: this isn't SRUable
[13:28] <Saviq> didrocks, oh
[13:28] <Saviq> didrocks, new package?
[13:28] <didrocks> Saviq: no packaging changes in SRU
[13:28] <jhodapp> didrocks, can I get a silo for fixing the mediaplayer-app autopilot tests? https://code.launchpad.net/~jhodapp/mediaplayer-app/fix-ap-tests/+merge/218075
[13:28] <didrocks> especially large like that one
[13:29] <Saviq> and they wanted to SRU all the unity8 development... :D
[13:29] <didrocks> jhodapp: oh, that easy? no need to ship the file in the .install one? (you already include the directory?)
[13:29] <didrocks> Saviq: and I warned them about it :)
[13:29] <didrocks> Saviq: you can try backports
[13:29] <plars> ogra_: how about if I try to flash a saucy image with phablet-flash? :)
[13:30] <didrocks> Saviq: talk first to the SRU team, but I doubt this will allow that as a SRU
[13:30] <ogra_> plars, nah, use something that can flash a recent image
[13:30] <jhodapp> didrocks, I just followed the example of what's already there, technically I don't maintain mediaplayer-app :)
[13:30] <ogra_> plars, when exactly did that start ? last udf upload was on wed.
[13:30] <plars> ogra_: well phablet-flash *should* be able to do trusty too
[13:30] <Saviq> didrocks, in that case I'll first try and understand the dependency issue the guy described there
[13:30] <didrocks> jhodapp: ok, did you check that the produced .deb contains the file?
[13:30] <jhodapp> didrocks, yeah
[13:31] <didrocks> jhodapp: good, assigning, one sec!
[13:31] <didrocks> Saviq: yeah can be :)
[13:31] <didrocks> better*
[13:31] <ogra_> plars, please try with the last trusty udf
[13:31] <jhodapp> didrocks, I built a .deb locally and installed it on device and ran the tests from that
[13:31] <didrocks> perfect :)
[13:31] <pmcgowan> Saviq, isnt it the problem from installing the sdk and getting all the unity8 stuff
[13:31] <plars> 0.2+14.10.20140429.1-0ubuntu1 is the one I'm on
[13:31] <jhodapp> didrocks, all of them pass now
[13:31] <plars> appears to be the latest
[13:32] <Saviq> pmcgowan, even so, I don't think it should remove modemmanager and such
[13:32] <pmcgowan> right
[13:32] <jhodapp> plars, FYI, fixed the mediaplayer-app AP tests, about to land them
[13:32] <plars> jhodapp: \o/
[13:32] <ogra_> plars, right, i want the one that was compiled with the former go toolchain
[13:32] <Saviq> I'll try in a chroot
[13:33] <ogra_> plars, thus .. the last trusty binary ...
[13:33] <didrocks> jhodapp: landing-017
[13:33] <didrocks> jhodapp: you can use the shortcuts at http://people.canonical.com/~rbpark/citrain/
[13:33] <jhodapp> thanks
[13:33] <plars> ogra_: this host isn't running trusty, let me see if I can pull it out from somewhere else
[13:33] <ogra_> just dpkg -i it worst case
[13:36] <jhodapp> didrocks, did you kick off a build, or that's all in my hands?
[13:36] <didrocks> jhodapp: that's all in your hands, you have the creds, right?
[13:36] <jhodapp> didrocks, yes I do, thanks
[13:37] <didrocks> yw ;)
[13:37] <didrocks> jhodapp: keep me posted once built, we can publish quickly
[13:37] <didrocks> and get an image out with it
[13:37] <jhodapp> awesome thanks
[13:37] <didrocks> thanks to you for the quick fix ;)
[13:38] <mhr3> didrocks, ehm, where's the build log? https://launchpad.net/~ci-train-ppa-service/+archive/landing-016/+build/5970787
[13:39] <didrocks> oh, interesting
[13:39] <didrocks> wgrant: any idea? $
[13:39] <didrocks> ^
[13:41] <bfiller> didrocks: package versioning question, what the correct version number scheme to use for this case of a backport 1) latest trusty version 0.0.67+14.04.20140408.1-0ubuntu2 2) utopic version 0.0.67+14.10.20140501-0ubuntu1 and I want to push the utopic fixes into a trusty ppa
[13:42] <bfiller> was thinking 0.0.67+14.10.20140501-0ubuntu1~trusty1 or something?
[13:44] <didrocks> bfiller: if you use the train, it will use the right versionning
[13:45] <didrocks> bfiller: it will be like 0.0.67+14.04.20140502-0ubuntu1
[13:45] <bfiller> didrocks: ok
[13:45] <bfiller> thanks
[13:46] <didrocks> yw!
[13:46] <bfiller> didrocks: another question - silo 4 I need to change one of the MR's and reconfigure. can't see how to do that from http://people.canonical.com/~rbpark/citrain/
[13:46] <Saviq> didrocks, ci train spreadsheet is locked for editing?
[13:46] <bfiller> I see recon link but not sure how to change the list
[13:46] <didrocks> bfiller: yeah, it's not possible, juts pastebin the results
[13:47] <didrocks> bfiller: mps and source packages
[13:47] <didrocks> (all of them)
[13:47] <didrocks> and I'll reconfigure for you
[13:47] <bfiller> ok
[13:47] <didrocks> Saviq: see the emails, the pastebin is going crazy
[13:47] <didrocks> spreadsheet*
[13:47]  * didrocks can't type
[13:47] <didrocks> Saviq: so you can ask for a landing directly
[13:48] <Saviq> didrocks, ok, http://pastebin.ubuntu.com/7379662/
[13:48] <didrocks> Saviq: seeing you as the lander, I guess?
[13:48] <Saviq> didrocks, yup
[13:48] <didrocks> uno momento!
[13:49] <didrocks> Saviq: landing-020, you got the latest!
[13:49] <Saviq> didrocks, thanks
[13:49] <didrocks> Saviq: you can get the links from http://people.canonical.com/~rbpark/citrain/
[13:49] <Saviq> didrocks, yup, saw it
[13:50] <pmcgowan> didrocks, bfiller so we can use CI train to target a PPA?
[13:50] <didrocks> pmcgowan: I designed it for it, (as for daily release), just a world of warning: we need to provision some time, this code has never run in production
[13:50] <didrocks> so probably the first landing will need som adjustement
[13:50] <didrocks> some*
[13:51] <pmcgowan> ok bfiller^^
[13:51] <bfiller> pmcgowan, didrocks : doing it manually for now
[13:52] <bfiller> it's just a dput
[13:53] <bfiller> didrocks: here is the reconfiguration info for silo 4: http://pastebin.ubuntu.com/7379671/
[13:54] <mhr3> wgrant, here's the full thing https://launchpad.net/~ci-train-ppa-service/+archive/landing-016/+sourcepub/4148955/+listing-archive-extra
[13:55] <didrocks> bfiller: done, you can rebuild
[14:01] <bfiller> didrocks: thanks
[14:01] <didrocks> yw
[14:13] <AlbertA> josepht: we are getting a failure on a bunch of MP's, seems to be the same: https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/2/console
[14:13] <AlbertA> "FATAL: Unable to find coverage results
[14:13] <AlbertA> hudson.util.IOException2: remote file operation failed: /home/ubuntu/jenkins/workspace/mir-team-mir-development-branch-utopic-amd64-ci at hudson.remoting.Channel@55ef4502:ps-precise-server-amd64-smp"
[14:13] <AlbertA> https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/4/console
[14:14] <AlbertA> https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/9/console
[14:16] <josepht> AlbertA: looking
[14:17] <josepht> AlbertA: it looks like a problem happens earlier with libeatmydata
[14:24] <jhodapp> didrocks, ok, it's ready to publish
[14:24] <kgunn_> didrocks: sorry if you got a bunch of pings on this already...i suspect spreadsheet is a headache atm....but currently i see mir 0.1.9 in the spreadsheet as if its not landed already, and line i added y'day is completely missing...like this is 4 days old or something
[14:24] <jhodapp> didrocks, just got done testing it on a fresh image 8
[14:24] <didrocks> jhodapp: perfect!
[14:24] <didrocks> doing so
[14:24] <jhodapp> thanks
[14:27] <ogra_> didrocks, so do you plan another image buuld today once unity8 and mediaplayer landed ?
[14:28] <ogra_> sounds close to promoteable if these two are fixed
[14:28] <didrocks> ogra_: agreed
[14:28] <ogra_> (if the tests actually agree indeed :) )
[14:30] <didrocks> yep
[14:30] <didrocks> kgunn_: so, as robru stated in the landing email, the spreadsheet has sync issue
[14:30] <didrocks> kgunn_: I turned it off read only
[14:30] <didrocks> kgunn_: if you have requests, just pastebin them, I cooked a manual way for us to assign things
[14:30] <didrocks> kgunn_: the backend status is reflected at http://people.canonical.com/~rbpark/citrain/
[14:30] <didrocks> (it's read only, but good enough to get links)
[14:31] <didrocks> and see if it built or not
[14:59] <AlbertA> josepht: ok so is it a transitive problem? should we try just retriggering those CI builds? or wait for a fix?
[15:00] <josepht> AlbertA: fginther is looking at it, there's a patch that needs to be applied to support utopic jobs
[15:01] <AlbertA> joshepth: gotcha thanks
[15:04] <ogra_> hmm, touch seed and meta upload ?!?
[15:04] <ogra_> didrocks, ^^^
[15:04] <ogra_> xnox, did you coordinate that with anykone from the landing team ?
[15:04] <didrocks> ogra_: didn't hear about anything
[15:05] <ogra_> xnox, we are currently holding back landings to get a promotable image
[15:05] <xnox> ogra_: .... which changed nothing.
[15:05] <ogra_> xnox, still a notification would have been nice
[15:06] <xnox> ogra_: i've used ci-train bot to verify that ubuntu-touch-meta is not in any landings.
[15:07] <ogra_> xnox, we have two meetings a day where we define what can go in and what cant ... and we have this channel ... some more communication would be good at times so we dont fall over backwards with heart attacks seeing it show up on -changes :)
[15:07] <ogra_> just a ping :)
[15:16] <xnox> ogra_: ok
[15:16] <xnox> ogra_: Oliver Grawert has been subscribed to this branch with:
[15:16] <xnox> Send notifications for both branch attribute updates and new revisions added to the branch.
[15:16] <xnox> Don't limit the size of the diff.
[15:16] <xnox> Send email about any code review activity for this branch.
[15:16] <xnox> https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.utopic
[15:16] <ogra_> heh, thanks
[15:16] <xnox> ogra_: diffs tell the story, instead of giving heart attacks.
[15:16] <ogra_> i get these when people request MPs
[15:17] <ogra_> just not for each and every commit
[15:17] <ogra_> xnox, i'm not the landing team though ... just one part of it
[15:18] <xnox> ogra_: i have no idea who the landing team are, who their tech-lead is, and their manager.
[15:18] <ogra_> also a seed change doesnt mean that meta gets uploaded immediately necessarily
[15:18] <ogra_> we often have it that it doesnt ...
[15:19] <ogra_> xnox, ... "ping: hey guys i'm uploading a new meta now" in this channel would really help
[15:19] <xnox> ogra_: yes it does need to go in, this is continegency against future autopilot / autopilot-legacy split. Such that whenever that lands, it will not break the images, since the image still depends on both python2 and python3.
[15:19] <xnox> autopilots that is.
[15:19] <xnox> ogra_: pinging people doesn't scale.
[15:19] <ogra_> landing team is always in this channel ...
[15:19] <ogra_> xnox, then feel free to attend the meeting ...
[15:19] <xnox> ogra_: not really =) yesterday was bank holiday for most of you.
[15:20] <xnox> ogra_: sorry, no time for meetings to busy landing srus and uploads.
[15:20] <ogra_> i'm sure didrocks will happily add you to the general invitation so you get notified
[15:20] <xnox> ogra_: it seems there are enough cooks in the kitchen as it is.
[15:20] <xnox> ogra_: there is no more insight i can provide.
[15:21] <ogra_> yes, but you always pass by our development model ... touch works different, this is not desktop
[15:21] <ogra_> and it always causes work to research what your change might influence ... knowing it in advance and having a single sentence explaining it would really help
[15:22] <ogra_> (and this is one of the purposes of this channel here)
[15:38] <mhr3> didrocks, 016 tested, ok to land
[15:46] <bfiller> didrocks: silo 012 tested and ok to land
[15:47] <didrocks> mhr3: bfiller: both are published
[15:47] <bfiller> didrocks: thanks
[15:48] <didrocks> yw
[15:52] <mhr3> ty
[16:02] <AlbertA> josepht: also it looks like the autolander is stuck:
[16:02] <AlbertA> josepht: https://code.launchpad.net/mir/+activereviews
[16:02] <AlbertA> josepht: we have some pending things to land that haven't landed in the last 10 hours
[16:03] <josepht> AlbertA: for landing issues you need to ping a CI Train support person
[16:04] <AlbertA> robru:^
[16:09] <robru> AlbertA, humm? Did anybody request a landing?
[16:09] <AlbertA> robru: should be autolander to our devel branch
[16:09] <AlbertA> robru: https://code.launchpad.net/mir/+activereviews
[16:09] <AlbertA> robru: all the ones marked ready to land have been stuck for about 10 hours
[16:10] <robru> AlbertA, hmm, that's not to do with ci train then. you should ask fginther about the autolander.
[16:10] <AlbertA> he funny I was pointed back and ci train
[16:10] <AlbertA> ok
[16:11] <AlbertA> fginther: any idea why the autolander is stuck for mir? ^
[16:11] <robru> AlbertA, hm, nope. ci train assigns PPAs for doing landings into distro, and it's very manual process with lots of testing. autolander is an unrelated syste
[16:11] <fginther> AlbertA, there was a hung job that caused a backup on the mako testing. It's moving again
[16:11] <AlbertA> fginther: oh ok thanks
[16:11] <fginther> AlbertA, Also I found the build problem and a fix will be in shortly
[16:12] <AlbertA> fginther: great! thanks for the support
[16:13] <josepht> AlbertA: sorry for sending you on a wild goose chase :/
[16:14] <AlbertA> josepht: np
[16:17] <fginther> josepht, can you review this MP to fix the mir builds? https://code.launchpad.net/~fginther/cupstream2distro-config/fix-mir-coverage/+merge/218118
[16:18] <josepht> fginther: looking now
[16:19] <robru> bfiller, kgunn_, mhr3, and any other landers: so the spreadsheet is still broken, but didier developed a workaround that will let me assign silos manually. so just email me with landing requests if you have any.
[16:20] <bfiller> robru: will do
[16:20] <robru> thanks
[16:21] <bfiller> robru: just sent you one :)
[16:22] <dbarth> didrocks: the livemail package i rebuilt this morning: https://launchpad.net/~ci-train-ppa-service/+archive/landing-011
[16:22] <dbarth> didrocks: it's not going magically back into the unappoved pocket afaict
[16:22] <didrocks> dbarth: can you check with robru? I'm EOW now :)
[16:22] <didrocks> dbarth: yeah, you need someone to republish it
[16:22] <dbarth> didrocks: sorry, sure
[16:22] <dbarth> robru: help! :)
[16:23] <dbarth> robru: i need just the livemail package in that ppa 011 to be re-published (it was missing the bug ref in the changelog)
[16:23] <dbarth> and then it can be re-acked by the release team
[16:24] <robru> dbarth, sure
[16:24] <kgunn_> robru: thanks
[16:24] <robru> kgunn_, you're welcome
[16:24] <fginther> josepht, thanks
[16:25] <robru> dbarth, seems there is still no bug reference? https://launchpad.net/~ci-train-ppa-service/+archive/landing-011/+sourcepub/4148440/+listing-archive-extra
[16:25] <dbarth> oh really?
[16:26] <dbarth> :/ i've added the branch to the bug for ref.
[16:26] <dbarth> well, i'll just upload a fixed changelog
[16:26] <dbarth> ah yeah, the mp has a changelog so CI doesn't change it i guess
[16:27] <robru> oh yeah, that would do it
[16:27] <robru> dbarth, no worries, just update the changelog, rebuild, then I can republish
[16:30] <robru> jhodapp, I'm merging silo 17 (mediaplayer-app)
[16:30] <jhodapp> robru, awesome, thanks!
[16:30] <robru> jhodapp, you're welcome ;-)
[16:30] <jhodapp> robru, that should fix all of the broken AP tests
[16:30] <robru> bfiller, merging silo 12, qtorganizer
[16:30] <robru> jhodapp, great!
[16:37] <mhr3> robru, ehm, something to be worried about? https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scope-click/
[16:38] <mhr3> robru, from update-excuses
[16:38] <mhr3> for unity-scopes-api
[16:38] <robru> hm
[16:41] <robru> mhr3, well, I'm having a hard time finding the actual log with the actual failure
[16:41] <mhr3> robru, https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scope-click/8/ARCH=amd64,label=adt/artifact/results/log ?
[16:42] <robru> hmmm, won't let me view it, i have to save it. strange
[16:43] <robru> oh good, test dependencies unsatisfiable
[16:43] <t1mp> is there a way I can see progress or an automerge queue for an MR that has been happroved but not (auto)merged yet?
[16:44] <robru> fginther, ^
[16:45] <robru> mhr3, no idea what's going on there. considering that it worked on i386, maybe it's infrastructural? maybe just run it again
[16:49] <mhr3> robru, i didn't even ask for it to be run
[16:49] <mhr3> robru, so can't exactly run it again :P
[16:49] <robru> mhr3, well how did it come to your attention? from trying to publish a silo or something?
[16:50] <mhr3> robru, was just looking at update-excuses cause -shell is already in release pocket, but -api isn't
[16:50] <robru> right
[16:51] <robru> mhr3, you should ping in #ubuntu-release channel. I'm not as familiar with those tests that they run in -proposed
[16:52] <robru> mhr3, but wait a bit though, because it does still say it's running (eg not finished)
[16:53] <mhr3> robru, hm, alright
[17:08] <robru> bfiller_afk, sorry for the delay (I had a lot of emails to read): I put your request in silo 12, and I started building for you since you're afk: https://ci-train.ubuntu.com/job/landing-012-1-build/26/console
[17:11] <mhr3> robru, tested 014, ready to land (once armhf is published)
[17:11] <robru> mhr3, sweet!
[17:22] <mhr3> robru, 014 really rdy now
[17:26] <fginther> AlbertA, is it ok if I re-approve the mir/devel branches that failed due to the jenkins coverage error?
[17:26] <robru> mhr3, ok, published! email me with any new landings you need ;-)
[17:26] <mhr3> robru, think i'll call it eow ;)
[17:26]  * mhr3 waves
[17:27] <fginther> t1mp, you can check the build queue and in progress jobs on http://s-jenkins.ubuntu-ci:8080/
[17:28] <fginther> t1mp, I'm assuming that's where the project you are interested in runs
[17:40] <AlbertA> fginther: yes
[17:41] <bzoltan> robru: rsalveti: cyphermox: the content of the Silo9 is ready to land ... all the tests are green and all the builds are fixed.
[17:41] <robru> bzoltan, great! on it
[17:42] <bzoltan> robru: Thanks
[17:43] <fginther> AlbertA, thanks, I've reapproved the MPs that failed due to the coverage error
[17:44] <robru> bzoltan, you're welcome!
[17:46] <bzoltan> robru: I am not sure if the builder got the ui-toolkit changelog correctly from the MR, but here is the correct log http://pastebin.ubuntu.com/7381010/
[17:46] <robru> bzoltan, oh... nope
[17:47] <robru> already hit publish, didn't realize anything was missing
[17:47] <bzoltan> robru:  no worries.. I can fix it in the next landing.
[17:48] <robru> bzoltan, amusingly it looks like the bug reference numbers survived without the messages: https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/+sourcepub/4149251/+listing-archive-extra
[17:49] <bzoltan> robru: wow.. that is odd :)
[17:57] <renato> robru, could you help me with this MR: https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/4465/console
[17:57] <renato> robru, jenkins is complaining about missing packages
[18:00] <robru> renato, oh, well it looks like your debian/control is set with too-restrictive versioning if I had to guess
[18:00] <robru> like it's set to = one specific version, and it's breaking because a newer version is being installed
[18:01] <robru> although the -dbg package seems to be opposite somehow
[18:01] <renato> robru, well, I always used that:  qtdeclarative5-ubuntu-contacts0.1 (= ${binary:Version}),
[18:01] <renato> this aways worked
[18:02] <robru> renato, what package is that? address-book-app?
[18:02] <renato> yes
[18:02] <robru> where's your debian/control?
[18:02] <renato> robru, the same source produce both packages
[18:02] <renato> robru, in the trunk/debian/control
[18:02] <robru> renato, where's your trunk? :-P
[18:03] <renato> lp:address-book-app
[18:03] <renato> robru, did you guys changed something in jenkins recently?
[18:03] <renato> robru, this was working well
[18:03] <robru> renato, not me... i just deal with ci train. maybe fginther knows ^^
[18:04] <robru> renato, yeah, based on that log, my only guess is that it should be >= instead of just =. But that jenkins stuff is more fginther's area
[18:05] <fginther> renato, looking
[18:09] <robru> brb, lunch
[18:10] <renato> fginther, I think I found the problem, one of the branches get released, and this increased the version. I need to mege all 17 pending branches now :(
[18:11] <t1mp> I just had an autolanding failure in UITK https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/50-headerTools/+merge/217586
[18:11] <t1mp> I don't know yet what's wrong, but it looks similar to renato's problem
[18:11] <t1mp> https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/4471/console
[18:14] <t1mp> :s Build timed out (after 60 minutes). Marking the build as failed.
[18:15] <fginther> t1mp, your MP failure is different, it's not an error due to unmet dependencies. I don't even see an error, will need to dig on this one.
[18:16] <fginther> renato, you don't need to manually merge those branches... jenkins does a merge to trunk before it builds the packages
[18:16] <t1mp> fginther: ok, thanks. I also don't see the error
[18:17] <fginther> renato, also I'm not exactly sure why your MP is failing, I think the dependency error may be incomplete
[18:18] <renato> fginther, what do you mean?
[18:19] <fginther> renato, I think the problem is that the appropriate version of qtdeclarative5-ubuntu-contacts0.1 can't be installed due to someone unmet dependency
[18:19] <fginther> I'm debugging
[18:20] <renato> fginther, thanks
[18:22] <fginther> renato, ahh, the problem is on qtdeclarative5-ubuntu-keyboard-extensions0.1. It can't find a package for this
[18:22] <renato> fginther, ok now make sense :D
[18:22] <renato> this package was not released yet
[18:24] <fginther> renato, I have no idea why apt-get can't come up with a reasonable error for that.
[18:28] <renato> fginther, thanks
[18:33] <fginther> t1mp, can you re-approve your MP. I just did a rebuild on the test job and it's working fine now: http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/4477/console
[18:36] <fginther> t1mp, just for grins, I'm going to retry it on both machines, to see if that provides different results
[18:36] <t1mp> fginther: ok, I happroved it again
[18:44] <t1mp> fginther: now I wait to see whether it succeeds?
[18:47] <fginther> t1mp, yes. If this is urgently needed to merge, that can be done, just let me know. Both of the test reruns I tried passed, I can't explain why it failed.
[18:48] <fginther> t1mp, the branch is running now
[18:48] <t1mp> fginther: if I can get this one and two following MRs merged this weekend that's fast enough :)
[18:49] <t1mp> fginther: do you know if I happrove two MRs that depend on each other, does autolanding automatically figure out that the prerequisite should merge first?
[18:49] <robru> fginther, hey, how were you able to determine that keyboard-extension package was the issue? I didn't see that in the log at all
[18:49] <fginther> t1mp, ok, I'll just let the system go on it's own.
[18:49] <t1mp> *they don't depend on each other, one depends on the other
[18:49] <robru> (just want to learn)
[18:49] <t1mp> fginther: sure, thanks
[18:49] <fginther> t1mp, yes, the pre-requiste has to merge first before the other two will be tested
[18:50] <fginther> robru, I had to interactively debug on the test machine.
[18:50] <robru> ah
[18:51] <fginther> robru, it sucks doing that :/
[18:51] <robru> yeah, I bet
[18:51] <t1mp> fginther: ok, thanks. Then I can already top-approve multiple MRs without waiting for the first one to land
[18:52] <fginther> t1mp, yes, that's safe to do
[20:44] <slangasek> is there any sort of list of known flaky tests?
[20:44] <slangasek> (cf. bug #1315524)
[20:52] <plars> ogra_: in case you are still around, rfowler_ confirmed that android ran fine on those devices. If you want to take a look at one remotely, one of them is even instrumented with relays on the power and volume buttons, so it can be forced into fastboot remotely