[07:20] <tvoss> good morning
[07:20] <tvoss> Mirv, good morning
[07:22] <Mirv> hi tvoss
[07:23] <tvoss> Mirv, looking at the sheet, line 9
[07:23] <tvoss> Mirv, I don't understand the comment there
[07:23] <tvoss> Mirv, could you explain to me what happened?
[07:29] <Mirv> tvoss: it seems it has been published, but is stuck in -proposed for some reason
[07:29] <Mirv> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dbus-cpp
[07:30] <Mirv> arm64 has failed to build, but it succeeded before: https://launchpad.net/ubuntu/+source/dbus-cpp/2.0.0+14.04.20140307-0ubuntu1
[07:30] <Mirv> seems to be the reason
[07:30] <Mirv> https://launchpadlibrarian.net/168638213/buildlog_ubuntu-trusty-arm64.dbus-cpp_2.0.0%2B14.04.20140307-0ubuntu1_FAILEDTOBUILD.txt.gz
[07:31] <tvoss> hmmm, that's weird
[07:38] <tvoss> cjwatson, good morning
[07:38] <tvoss> cjwatson, I get a build failure here https://launchpadlibrarian.net/168638213/buildlog_ubuntu-trusty-arm64.dbus-cpp_2.0.0%2B14.04.20140307-0ubuntu1_FAILEDTOBUILD.txt.gz
[07:39] <didrocks> Mirv: hey, can you provide an url if you still have the same issue?
[07:39] <didrocks> for the silo stuff
[07:40] <didrocks> oh found the issue
[07:40]  * didrocks fixes
[07:40] <didrocks> ah no
[07:40] <didrocks> hum
[07:41] <Mirv> didrocks: I haven't yet retried since I thought you'd take a glance first
[07:41] <didrocks> Mirv: yeah, please give me a link
[07:41] <didrocks> you didn't in your email
[07:42] <Mirv> didrocks: it's in my last e-mail bu http://162.213.34.102/job/prepare-silo/421/console
[07:42] <didrocks> Mirv: ah, ok, was still on the first one
[07:42] <didrocks> thanks
[07:42] <didrocks> yeah, weird that we have WARNING:root:Can't load configuration: No JSON object could be decoded
[07:42] <didrocks> Mirv: I'll look in a few
[07:42] <Mirv> yep, that one is weird
[07:43] <Mirv> yeah, no hurry. I found 4 more packages not yet in landing PPA, and 3 of them are manual uploads which I'm doing now.
[07:46] <didrocks> ok, we'll get that fixed
[07:46] <didrocks> the logic seems good, so it's like it can't find the initiale configuraiton
[07:46] <didrocks> I'll check with debug :)
[07:46] <didrocks> (10 minutes)
[07:58] <didrocks> Mirv: ah, interesting, the config file is empty
[07:59]  * didrocks restore and try
[07:59] <didrocks> Mirv: did you have any failure previously on that silo?
[08:00] <didrocks> Mirv: and after that, all work like expected. It would be interesting to know what lead in your silo to have that empty config file
[08:02] <didrocks> Mirv: running http://162.213.34.102/job/prepare-silo/423/console btw
[08:07] <Mirv> didrocks: the only thing I did was aborting build job, because of a ppc64el build that the system thought was building while it was not
[08:08] <Mirv> didrocks: I got the error twice in the row and stopped at that. interesting.
[08:08] <didrocks> Mirv: yeah, shouldn't happen
[08:08] <didrocks> Mirv: tell me next time you see it, I'll be interested in fixing this bug
[08:08] <didrocks> not sure, I try to always have transactional writes
[08:08] <Mirv> sure, I will
[08:08] <didrocks> thanks ;)
[08:09] <didrocks> Mirv: on your question: please for those package, just disable them in daily release
[08:09] <didrocks> + upstream merger and so on
[08:09] <didrocks> (the 3 lines)
[08:10] <Mirv> didrocks: ok, thanks, I'll disable those: dee-qt qtpowerd poppler-qml-plugin u1db-qt ubuntu-system-settings-online-accounts unity-scope-online-music click-update-manager clickmanager-plugin ubuntu-purhase-service
[08:12] <Mirv> well, some of them already are, but anyhow
[08:23] <didrocks> ok ;)
[08:23] <popey> bug 1289804
[08:23] <popey> seems we have a memory leak issue..
[08:23] <popey> (not just music-app)
[08:23] <didrocks> popey: blocker in your opinion?
[08:23] <popey> been there a while
[08:24] <popey> but worse than it was in #194.
[08:24] <didrocks> popey: they will tell you they will only look with 5.2 :p
[08:24] <popey> we tested with 5.2 too..
[08:24] <popey> https://bugs.launchpad.net/music-app/+bug/1289804/comments/9
[08:25] <didrocks> popey: argh, ok
[08:25] <popey> so no, not a blocker to #226
[08:25] <popey> it manifests itself in music because it's unconfined, you can get any app to eat ram by keeping it alive with taps
[08:25] <popey> so it certainly needs examination
[08:26] <didrocks> yep :)
[08:26] <didrocks> hum
[08:26] <popey> my phone was unusable after 20 hours of uptime and no usage ☻
[08:26] <didrocks> I received the notification for the team meeting
[08:26] <popey> americans changed TZ
[08:26] <didrocks> meaning the meeting is not set in UTC?
[08:26] <popey> it moved here too
[08:26] <popey> (the meeting moved) - it shows at 08:30 UTC
[08:26] <didrocks> let me adjust the time again
[08:27] <popey> probably the Ubuntu Engineering calendar is USA TZ
[08:27] <ogra_> didrocks, you will have to adjust back on the 30th
[08:27] <didrocks> ogra_: yep
[08:27] <didrocks> popey: weird, the Tz set for it is "France" though
[08:28] <didrocks> anyway, let's move them
[08:28] <didrocks> and we'll move them back
[08:28] <didrocks> oh, there is one everyday?
[08:28] <didrocks> it's a separate one :p
[08:28] <didrocks> ah no, phew
[08:28] <didrocks> just long to refresh
[08:28] <popey> no, they are separate
[08:29] <popey> i moved some ☻
[08:29] <didrocks> ahah :)
[08:29] <didrocks> the 6PM as well?
[08:29] <didrocks> or they didn't move?
[08:30] <popey> oof, I broke, let me fix
[08:30] <didrocks> removing as well meetings during vUDS
[08:31] <popey> ah yes
[08:33] <didrocks> vUDS is so empty!
[08:33]  * didrocks scheduled last client meetings in seb128's track
[08:33] <didrocks> hehe :)
[08:40] <popey> didrocks: who 'owns' ubuntu-emulator? xnox?
[08:40] <didrocks> popey: yeah, the biggest contributors are xnox/cjwatson/rsalvetti AFAIK
[08:40] <popey> hm, ok
[08:41] <tvoss> didrocks, good morning
[08:41] <sil2100> Finally made it
[08:42] <sil2100> Morning!
[08:42] <didrocks> hey tvoss, morning
[08:42] <didrocks> hey sil2100 :)
[08:42] <didrocks> popey: anything we should be worried about?
[08:42] <popey> saw a couple of people in -touch mention that their emulator wasn't starting. I tried this morning and I can't get it to build a working image either
[08:42] <popey> just get a black screen
[08:42] <tvoss> didrocks, sil2100 the dbus-cpp landing seems to be stuck in proposed due to arm64 not building. However, the compilation fails with the compiler complaining about -fstack-protector missing
[08:43] <tvoss> didrocks, sil2100 the interesting bit is: I think I don't set that explicitly somehwere
[08:43] <popey> trying again from clean.
[08:44] <didrocks> tvoss: it's the distribution default
[08:44] <tvoss> didrocks, that's interesting that it fails on arm64 then :)
[08:44] <tvoss> didrocks, https://launchpadlibrarian.net/168638213/buildlog_ubuntu-trusty-arm64.dbus-cpp_2.0.0%2B14.04.20140307-0ubuntu1_FAILEDTOBUILD.txt.gz
[08:44] <didrocks> tvoss: https://wiki.ubuntu.com/ToolChain/CompilerFlags
[08:45] <didrocks> tvoss: I guess it's something to check with doko, I have no clue about arm64 if it's supposed to support stack-protector or not
[08:45] <sil2100> tvoss: hmm, well, there was no way to test it beforehand on arm64, as I can't set up a arm64 chrrot even
[08:45] <didrocks> and if so, why it's set
[08:45] <sil2100> tvoss: strange thing - why didn't it fail for the previous dbus-cpp builds?
[08:46] <didrocks> tvoss: and yeah, I confirm that you don't seem to do anything with the flags that can set it on that arch
[08:46] <didrocks> (and so override potential defaults)
[08:46] <didrocks> but you force 4.7
[08:46] <didrocks> and I'm unsure 4.7 has the right defaults for that arch, I guess doko only cares about 4.8
[08:46] <didrocks> tvoss: that can be a lead to discuss about it with him I think ^
[08:50] <didrocks> sil2100: previous version was built with 4.7 or 4.8?
[08:54] <sil2100> hm, with 4.7
[08:54] <sil2100> didrocks: since the whole issue we had with location-service being 100% CPU was caused by the 4.7/4.8 incompatibility
[08:54] <didrocks> sil2100: ok, weird then
[08:55] <didrocks> I think tvoss has enough information to know where to look at anyway :)
[08:55] <cjwatson> tvoss: Morning.  arm64 doesn't have stack-protector.  Why are you forcing that, though, given that -fstack-protector is on by default in Ubuntu anyway?
[08:55] <sil2100> So we pushed a force rebuild on 4.7 + the symbols hack
[08:55] <cjwatson> didrocks: emulator> not me
[08:55] <sil2100> Strange anyways!
[08:55] <tvoss> cjwatson, I'm *not* forcing it
[08:55] <didrocks> cjwatson: I don't see it in his build flags though, but he's using gcc 4.7, do you think that disabling stack-protector can be missing on that versioN?
[08:55] <cjwatson> didrocks: It's explicitly on the command line
[08:56] <cjwatson> So it's not GCC's fault :)
[08:56] <cjwatson> Wonder if it's cmake
[08:56] <didrocks> yeah, I'm looking into that direction
[08:56] <cjwatson> Or dpkg-buildflags
[08:56] <didrocks> nothing special on the configure flags
[08:56] <cjwatson> I'd have thought dpkg-buildflags shouldn't have -fstack-protector on arm64 though
[08:57] <didrocks> well, I guess all packages would fail otherwise…
[08:59] <cjwatson> that command line does look awfully like dpkg-buildflags though
[09:00] <didrocks> yeah, followed by --param=ssp-buffer-size=4 and so on, with -g -O2 before…
[09:01] <cjwatson> Oh
[09:01] <cjwatson> dpkg (1.17.5ubuntu5) trusty; urgency=medium
[09:01] <cjwatson>   * Allow -fstack-protector on arm64 now that GCC and glibc support it.
[09:01] <cjwatson>  -- Adam Conrad <adconrad@ubuntu.com>  Fri, 07 Mar 2014 18:47:57 +0800
[09:01] <didrocks> here we go
[09:01] <cjwatson> So gcc-4.8 supports it, but of course dbus-cpp is forcing gcc-4.7
[09:01] <didrocks> tvoss: you have your infos ^
[09:01] <cjwatson> tvoss: export DEB_CXXFLAGS_MAINT_STRIP := -fstack-protector
[09:02] <cjwatson> well, conditional on arm64
[09:02] <cjwatson> so, in debian/rules:
[09:02] <tvoss> cjwatson, so that's in debian/rules?
[09:02] <cjwatson> ifeq (arm64,$(DEB_HOST_ARCH))
[09:02] <cjwatson> export DEB_CXXFLAGS_MAINT_STRIP := -fstack-protector
[09:02] <cjwatson> endif
[09:02] <cjwatson> should do it
[09:02] <cjwatson> with a comment that this is because g++-4.7 doesn't have SSP, and it can go away if/when you move to 4.8
[09:04] <cjwatson> didrocks,Mirv: the ppc64el build in question was a build *failure*, not so much "building" although that's how the job described it
[09:04] <didrocks> cjwatson: something stripped out the status file, so it wasn't refreshed anymore. So don't take into account the status reported in that case
[09:05] <cjwatson> didrocks,Mirv: that was qttools-opensource-src, which we got building later
[09:05] <cjwatson> it was definitely not building at the time
[09:05] <cjwatson> or rather it was definitely failed at the time
[09:05] <didrocks> cjwatson: I'm maybe out of context for that last ping, but the job was running or you were talking about the jenkins job iself?
[09:05] <didrocks> itself*
[09:06] <Mirv> cjwatson: I think since it started on Friday, it had not yet been build at all. the first failure of qttools was then on Saturday after copy-package https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+builds?build_text=qttools&build_state=all
[09:06] <cjwatson> I don't know the distinction
[09:06] <cjwatson> Mirv: it was dep-wait on qtdeclarative at the time - I checked
[09:06] <Mirv> but on Friday (until Saturday) CI Train was under impression there was a build of ppc64el that was building
[09:06] <cjwatson> that's why I sent you a qtdeclarative porting branch
[09:06] <Mirv> cjwatson: this is what I aborted originally http://162.213.34.102/job/landing-006-1-build/65/console
[09:06] <cjwatson> I was explicitly working on clearing up that job :)
[09:06] <Mirv> cjwatson: aha, ok
[09:07] <cjwatson> from my point of view the ci-train job was entirely correct - I mean, regardless of fine distinctions, it'd have got stuck in proposed-migration due to the missing ppc64el build, so it was right to fix it
[09:08] <tvoss> sil2100, pushed an update to https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-race-and-add-tests
[09:08] <tvoss> sil2100, can you trigger a rebuild?
[09:09] <didrocks> tvoss: that should be before the include I guess
[09:09] <didrocks> (and you can retrigger yourself normally, with ignore step and only set the component you want to rebuild with only rebuild)
[09:10] <didrocks> you don't need sil2100 for that
[09:10] <sil2100> tvoss: you can rebuild yourself :)
[09:10] <cjwatson> include> I don't know if it matters, but can't hurt to move it earlier
[09:11] <sil2100> tvoss: just find the silo on the spreadsheet, press rebuild, log into jenkins (SSO) and press build
[09:11] <sil2100> tvoss: maybe write to only 'rebuild' dbus-cpp
[09:12] <didrocks> cjwatson: ah ok, I was under the impression it was looking for the definition in the env first and won't look at it again, but I just skimmed over the makefile for that, so you're probably more exact than I am. Thanks :)
[09:12] <sil2100> didrocks: how do we handle cases when a silo is already in the 'releasing, stuck in proposed' state?
[09:12] <sil2100> tvoss: wait a moment with that if anything
[09:12] <didrocks> sil2100: just rebuild what's needed to be rebuilt and I think you will need the "ignore step" option
[09:13] <sil2100> didrocks: ok
[09:13] <didrocks> then, it will rebuild only that component, and track it
[09:13] <sil2100> tvoss: let me help you in that then, I'll do this
[09:13] <didrocks> (however, it will recollect all commits since latest version in the release pocket and upload with -v)
[09:13] <tvoss> sil2100, ack
[09:13] <cjwatson> didrocks: this is one of those things where I'd have to read the GNU Make manual carefully, and it's not worth it :)
[09:13] <didrocks> but that was only tested in labs, it's the first time in production :)
[09:13] <didrocks> cjwatson: heh, indeed :)
[09:14] <sil2100> didrocks: uuuu ;p Ok, let's try that then
[09:15] <sil2100> didrocks: hmmm... I just noticed my mail, I probably missed something, but was todays landing meeting moved to an earlier hour?
[09:16] <didrocks> sil2100: it was, weirdly (probably due to US dailylight saving switch)
[09:16] <didrocks> sil2100: so I rescheduled at the correct time
[09:16] <sil2100> My google calendar said 9:30 till 10, like one hour earlier than normally :o Did I miss it?
[09:16] <sil2100> Ah
[09:16] <sil2100> Ok ;)
[09:16] <didrocks> sil2100: your google calender should have it updated?
[09:17] <sil2100> didrocks: ah, right, calendar has the correct date, but I didn't get a confirmation of the change on e-mail, so I was a bit shocked
[09:17] <sil2100> THanks ;)
[09:18] <didrocks> yeah, I avoided to spam all of you
[09:26] <sil2100> tvoss: let's wait for it to re-build
[09:26] <tvoss> sil2100, ack
[09:31] <didrocks> popey: coming?
[09:32] <popey> omw
[10:01] <cjwatson> Mirv: given that we'll be waiting for arm64 to build everything, I would suggest blocking the set of packages in the Qt5.2 silo in proposed-migration
[10:01] <cjwatson> (once you push the button)
[10:01] <cjwatson> just to avoid accidents with partial promotions
[10:03] <popey> didrocks: who should I poke https://bugs.launchpad.net/music-app/+bug/1289804 with?
[10:03] <didrocks> popey: reboot worked for you?
[10:03] <popey> yes didrocks
[10:04] <didrocks> popey: ok, I don't have it either here in a fresh flashed image
[10:04] <didrocks> worth keeping it in mind and see
[10:04] <popey> will keep an eye out for it on future updates
[10:04] <didrocks> thanks
[10:04] <didrocks> popey: for bug #1289804, I would say let's start with upstream, so osomon/bfiller
[10:04] <Mirv> cjwatson: ok, didrocks can probably set the block, at least if it turns out we enable the arm64 builds but then suddenly make a decision tomorrow or so about actually landing it
[10:05] <Mirv> arm64 is going to be interesting, starting with qtbase where doko told the arm64 patches can be dropped with 5.2, I hope it's so
[10:06] <didrocks> davmor2: oh btw, can you dogfood image #229? We'll get it in our bag for promotion :)
[10:06] <didrocks> Mirv: yeah, better to prepare it
[10:06] <didrocks> Mirv: when is that meeting? Maybe I should come this time
[10:07] <davmor2> didrocks: yeah no worries
[10:07] <Mirv> didrocks: umm, I now see the meeting is no more this week, at least currently. it used to be 14:00 UTC
[10:07] <didrocks> Mirv: interesting…
[10:07] <didrocks> Mirv: wasn't moved to one hour later? (as many meeting due to US TZ change)
[10:07] <didrocks> meetings*
[10:08] <Mirv> didrocks: no, just not there. probably set to be daily "until we've probably shipped it" or so :)
[10:08] <didrocks> Mirv: yeah ;)
[10:08] <Mirv> the unity8 AP problem might have a fix now, since I rebuilt qtbase with a fix suggested from unity people
[10:09] <didrocks> Mirv: tell me if you need anything, but I clearly think that we should continue on what was discussed Friday: only the expected AP failure
[10:09] <didrocks> ok
[10:09] <Mirv> weather app I think was already seen to be broken, probably needs fixes for 5.2
[10:09] <didrocks> expected == clock apps as from today
[10:09] <Mirv> it'd be nice if gallery app could be tested somehow
[10:09] <didrocks> and 2 weather apps ones
[10:09] <didrocks> ah no, it's one on weather-app
[10:10] <didrocks> Mirv: so, we expect only 1 clock AP test failure + 1 weather AP test failure
[10:10] <didrocks> all the rest needs to be investigated
[10:10] <Mirv> didrocks: I checked that online-acounts does have the revert in it
[10:10] <didrocks> Mirv: the run from Friday?
[10:10] <didrocks> AP test run?
[10:11] <didrocks> (the code where we see it failing shouldn't be in the revert at all)
[10:11] <Mirv> didrocks: hmm, actualy, it's a good question whether the AP run or the Friday's online-accounts rebuild was there first..
[10:11] <Mirv> didrocks: so that's probably then it
[10:11] <didrocks> Mirv: ok, worth having a look anyway :)
[10:12] <Mirv> didrocks: I originally btw thought that if 5.0 image can be promoted, it's good to land 5.2, but you think we continue at least for now seeking to do 100% smooth transition (where, nearer to it than current situation)?
[10:12] <Mirv> I wonder if UI Freeze on Thursday poses a problem
[10:12] <didrocks> Mirv: yeah, otherwise, we'll never recover and block everyone else not part of the transaction
[10:13] <didrocks> Mirv: why? we have FFe for our components (and it doesn't change the UI)
[10:13] <Mirv> true enough, nothing should change UI wise
[10:13] <didrocks> Mirv: we can't ask blocking the whole distro again on pushing something not ready when we know it's not ready yet
[10:13] <didrocks> that won't make it more "ready"
[10:15] <Mirv> I don't think anyone is currently working on the 5.2 related AP problems, though, yet
[10:15] <Mirv> that should change, of course
[10:15] <didrocks> Mirv: that should have been the focus as well of the 5.2 meetings though
[10:16] <didrocks> yeah
[10:16] <Mirv> didrocks: the problem was that for most of the last week the AP runs were not working because of the adb/makodevice problems
[10:16] <Mirv> now we've that one run finally
[10:16] <didrocks> Mirv: which issue?
[10:17] <didrocks> Mirv: something we don't have on ci.ubuntu.com?
[10:17] <Mirv> didrocks: I mean the AP runs were not possible to do because of http://q-jenkins:8080/job/autopilot-release-gatekeeper/61/console
[10:17] <Mirv> first the adb problems and then the connection to mako:s not working, elopio & his team were then onto it
[10:18] <didrocks> Mirv: ok, so infra issues mostly?
[10:18] <Mirv> didrocks: yes
[10:18] <didrocks> Mirv: anyway, we discussed about the AP tests on Friday with elopio and asac as well agreed with me
[10:18] <didrocks> Mirv: so I don't think that will come to a surprise
[10:19] <Mirv> yeah. so trying to fix those should continue together with the DPR issue fix.
[10:21] <didrocks> yep
[10:24] <tvoss> sil2100, didrocks I'm kinda lost with the dbus-cpp landing now
[10:25] <sil2100> tvoss: ok, wait, it finished building
[10:25] <cjwatson> didrocks,Mirv: landing-006 has arm64 now, so can you please copy everything in that PPA into itself?
[10:25] <sil2100> tvoss: let's do a quick test-spin on a device if all is ok and then re-publish
[10:26] <cjwatson> (let me know if you need a canned command line)
[10:26] <didrocks> Mirv: you are handling the copy?
[10:26] <tvoss> sil2100, okay, I will give it a spin, too
[10:26] <tvoss> sil2100, could you try it, too?
[10:26] <cjwatson> copy-package -p ci-train-ppa-service --ppa-name landing-006 -b <list of all the source packages>
[10:26] <sil2100> tvoss: sure, doing that now
[10:27] <tvoss> sil2100, thanks
[10:27] <Mirv> cihelp infrastructure problems running AP tests http://q-jenkins:8080/job/autopilot-release-gatekeeper/64/ - previous successful run on Friday
[10:28] <Mirv> didrocks: ok, handling the copy
[10:28] <didrocks> thanks :)
[10:32] <Mirv> actually, I'll not copy everything, since not everything build-deps on the new Qt. so starting with Qt itself which is all set up good regarding dependencies
[10:33] <cjwatson> why the backup-landing1?
[10:33] <cjwatson> oh ye of little faith
[10:35] <Mirv> cjwatson: too much to lose :)
[10:35] <cjwatson> you couldn't copy it back without generating at least some new builds anyway ... but ok
[10:37] <ogra_> hmm, promoting takes loong with so many arches
[10:38] <Mirv> actually, I will start by qtbase only because that's the one with the libqt5core5 -> libqt5core5a change
[10:38] <cjwatson> reasonable, yeah
[10:38] <sil2100> wow
[10:39] <Mirv> and so it begins
[10:41] <sil2100> hmmm, what a nice bug I got!
[10:43] <didrocks> sil2100: on the double promotion for fixing something stuck into proposed? It's possible as I only tested that case in lab :)
[10:44] <sil2100> didrocks: no no, on 229 ;) I'll show a photo of that, it's just a funny thing, I guess it's just some layouting issue or something ;p
[10:45] <didrocks> ah :)
[10:46] <ogra_> grmpf ...
[10:46] <ogra_> promotion of 226 on mako runs since 13min ... doesnt move ...
[10:52] <didrocks> ogra_: still stuck?
[10:52] <ogra_> yes
[10:52] <ogra_> 29071 pts/1    S+    16:12 /usr/bin/python /srv/system-image.ubuntu.com/bin/copy-image trusty-proposed trusty mako 226 -k
[10:52] <didrocks> so, we'll need stgraber?
[10:52] <ogra_> runs sine 16:12
[10:52] <ogra_> yes, i think so
[10:52] <ogra_> seems copy-image also doesnt produce any logs
[10:53] <ogra_> it just sits there (seems to be in running state though)
[10:53] <cjwatson> might just be rechecksumming or something
[10:53] <ogra_> i see it updated the timestamp for the output dir though
[10:53] <cjwatson> 29071 pts/1    S+    16:14  |                   \_ /usr/bin/python /srv/system-image.ubuntu.com/bin/copy-image trusty-proposed trusty mako 226 -k
[10:53] <cjwatson>  2963 pts/1    Rl+    0:33  |                       \_ pxz -z -9 -c /tmp/tmpgcbAS5/output.tar
[10:53] <cjwatson> looking at more of the process tree helps :P
[10:53] <ogra_> sigh ... we have 6 arches to promote
[10:53] <cjwatson> I'm sure it'll get there
[10:53] <ogra_> that will take 1.5h now
[10:54] <cjwatson> xz compression just takes a while
[10:54] <ogra_> yeah, but it used to be a matter of 1-2min before
[10:54] <cjwatson> then why will it take 1.5h now?
[10:54] <cjwatson> 1-2min * 6 != 1.5h
[10:54] <ogra_> i guess that we havent promoted anything in rwo weeks might play a role for the diffing
[10:54] <ogra_> cjwatson, it used to take 1-2min ... if it takes 15 per arch now it will take a small century :)
[10:55] <ogra_> ah, it moved
[10:55] <cjwatson> does it matter for this particular run? :)
[10:55] <Mirv> cjwatson: ok doesn't start too well https://launchpadlibrarian.net/168944721/buildlog_ubuntu-trusty-arm64.qtbase-opensource-src_5.2.1%2Bdfsg-1ubuntu6_FAILEDTOBUILD.txt.gz
[10:55] <ogra_> not anymore, no ... i would have waited with starting it though ... since i have to go afk in 10min
[10:55] <Mirv> the patches that were there with 5.0.2 were http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src/revision/140
[10:56] <cjwatson> ogra_: it got through manta pretty quick, so *shrug*
[10:56] <ogra_> oh, seems the other arches run faster
[10:56] <cjwatson> Mirv: so what thinks it needs to use -m64?
[10:56] <ogra_> grr
[10:56] <ogra_> http://paste.ubuntu.com/7067002/
[10:57] <cjwatson> Mirv: oh right, easy
[10:57] <cjwatson> Mirv: http://paste.ubuntu.com/7067006/
[10:58] <cjwatson> that's for arches where -m64 doesn't make sense
[10:59] <Mirv> cjwatson: ok, and I don't see other similar things in debian/rules so I guess worth a rerun unless there's a test PPA to use
[10:59] <cjwatson> you used to have a separate if case for it, you just moved arm64 to the wrong place
[11:00] <cjwatson> http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src/view/140/debian/rules lines 69-72
[11:00] <davmor2> Morning all
[11:00] <cjwatson> Mirv: probably worth just rerunning in 006
[11:00] <Mirv> ok
[11:02] <mandel> ogra_, do you know how is the qt 5.2 thing going?
[11:02] <ogra_> mandel, Mirv does ;)
[11:03] <Mirv> mandel: https://bugs.launchpad.net/webbrowser-app/+bug/1207270 needs to be fixed and some AP tests are failing http://q-jenkins:8080/job/autopilot-release-gatekeeper/63/
[11:03] <mandel> Mirv, thx
[11:04] <ogra_> mandel, Mirv does ;)
[11:04] <ogra_> oops
[11:04] <ogra_> sorry
[11:04] <Mirv> I do, I do
[11:04] <ogra_> heh, EFOCUS
[11:04] <Mirv> and that's why I've prevented 'up' binding in irssi, requiring ctrl-up
[11:06]  * ogra_ needs to go afk now for like 20min ... i'll check the promotion later ... looks like mako might need a re-run 
[11:06] <mandel> Mirv, we need to fix that ogra_ bot, it has some weird stammer
[11:07] <ogra_> heh
[11:15] <tvoss> sil2100, ping
[11:16] <tvoss> sil2100, any luck with the dbus-cpp packages?
[11:16] <tvoss> sil2100, didrocks can I get a silo for line 34?
[11:17] <didrocks> tvoss: unity-mir is part of the qt 5.2 landing
[11:17] <tvoss> didrocks, oh okay
[11:18] <sil2100> tvoss: still checking out - looks ok from the outside, but I still couldn't get location working yet
[11:19] <tvoss> sil2100, location not working as in?
[11:23] <sil2100> tvoss: can't force webbrowser to use location data after enabling it in the indicator
[11:24] <sil2100> popey, davmor2: does location work properly for you on stock 229 ?
[11:24] <tvoss> sil2100, the indicator is not fixed with my changes. Also: it might take 15 minutes to acquire a fix
[11:24] <popey> sil2100: define "work"
[11:26] <sil2100> popey: after enabling the indicator, does opening a webbrowser prompt you for allowing location on google maps and then it finally finds the GPS signal?
[11:26] <popey> sil2100: i have _never_ had success in a browser finding location
[11:26] <davmor2> sil2100: haven't tried it yet, ignore the indicator though it lies
[11:27] <popey> tell you what is odd though
[11:28] <popey> open browser, visit maps.google.com, kill browser, start again.
[11:28] <popey> The first time you get mobile version of gmaps, second time you get desktop version
[11:28] <davmor2> popey: because you click on the link for maps right
[11:29] <davmor2> popey: -https:// always links to the mobile site, if you click on the link it the address bar it always goes to desktop
[11:31] <ogra_> hmm, so promoting mako and generic failed ... re-running for these two
[11:32] <popey> no
[11:32] <popey> i didnt click any link
[11:32] <popey> i opened browser
[11:33] <ogra_> ugh, and flo too ...
[11:33]  * ogra_ sighs
[11:34] <davmor2> sil2100: osmtouch has me pinpointed nicely so I assume gps is working
[11:38] <popey> davmor2: osmtouch doesn't use gsm
[11:38] <popey> *gps
[11:39] <davmor2> popey: It's stops flashing the warning there is no gps and pinpoints you precisely when there is a fix and google maps works then too
[11:41] <davmor2> popey: initially it doesn't I agree but then it tells you it isn't using gps and also tells you that the position is approximate
[11:45] <davmor2> popey, didrocks, ogra_: screen has just frozen again, this time 2 apps open and I swiped to get back to the dash chasing up on #ubuntu-mir channel but not seeming to get a response yet,  I'll carry on dogfooding on the n7 for a bit
[11:45] <didrocks> davmor2: thanks
[11:46] <ogra_> davmor2, make sure to back up syslog and the output of dmesg ... and probably also logcat
[11:47] <davmor2> ogra_: thanks will do that now, the phone is working fine just not the screen
[11:47] <ogra_> right
[11:47] <popey> davmor2: Mar 10 11:47:38 ubuntu-phablet com.ubuntu.location[893]: SV status update: [#svs: 23]
[11:47] <popey> i get 23 satellites in view and it still cant get a lock
[11:47] <ogra_> syslog should show OOM if there is any OOM going on ... and logcat should show any graphics driver issues
[11:48] <davmor2> popey: just checked top and there is no swap being used so it's not the issue you saw
[11:48] <popey> it takes a long time to use swap
[11:48] <popey> you need an app to be open for hours
[11:49] <davmor2> popey: ah okay so no :)
[11:51] <sil2100> tvoss: didn't test location properly yet but all seems to be ok I think
[11:51] <ogra_> sigh .... and generic failed again ... as did flo
[11:51] <sil2100> Let's publish (again)
[11:51]  * ogra_ re-runs again with these two arches
[11:53] <didrocks> ogra_: keep logs for Stéphane I guess
[11:53] <didrocks> ogra_: btw, as mako is promoted, it's now show up as promoted on the dashboard :p
[11:54] <ogra_> yeah, indeed
[11:58] <popey> davmor2: for me, it always says no gps
[11:59] <davmor2> popey: let me get it install on the n7
[12:12] <sil2100> didrocks: http://162.213.34.102/job/landing-003-2-publish/lastSuccessfulBuild/artifact/packaging_changes_dbus-cpp_2.0.0+14.04.20140310-0ubuntu1.diff <- packaging change ;)
[12:12] <tvoss> sil2100, ack and thx
[12:13] <tvoss> sil2100, I got a fix here, standing on the balcony and waiting for ~8 minutes
[12:13] <didrocks> sil2100: looks good to me
[12:19] <sil2100> didrocks: thanks ;) Let's see how it goez
[12:23] <davmor2> popey: this is all I get once I have a lock http://ubuntuone.com/4HwOplWn8pgR3yWMU1Hq7e until then it shows me in bushbury about a mile and a half away and says it's a guess :)
[12:25] <sil2100> didrocks: so, can I now publish only one component that was re-built? Since I rebuilt only dbus-cpp, publish job says that others (platform-api and location-service) weren't rebuilt - can I safely tell him to ignore those and just push dbus-cpp out? No need to re-release the others, no changes or rebuilds required there
[12:26] <didrocks> sil2100: yeah, just use the ignore flag
[12:26] <popey> davmor2: how do you know when you have a gps lock?
[12:26] <sil2100> *click*
[12:27] <davmor2> popey: I keep clicking on the My location button either in maps.google.com or osmtouch till it is right :)
[12:28] <sil2100> didrocks: all seems to work fine! o/
[12:28] <didrocks> :)
[12:28] <ogra_> didrocks, so i promoted on all arches now manually bit by bit ... sald yi messed up on flo so that it is called 207 there ... will sort that ut once stgraber is up
[12:28] <didrocks> ogra_: ok, thanks a lot! :)
[12:29] <davmor2> popey: maps.google.com tends to show position correctly when osmtouch does though up until then it says no gps location or words to that effect
[12:29] <ogra_> smells like the import job that runs every 5 min to check for new cdimage files makes it fall over ... once i disabled it i could at least run copy-image manually for each arch
[12:36] <didrocks> sil2100: as you can see, it's tracking the right version of dbus-cpp
[13:01] <cjwatson> Mirv: looks like qtbase/arm64 is good now
[13:02] <Mirv> cjwatson: yes, I was just refreshing Packages file and starting landing the rest of the Qt modules
[13:05] <Mirv> done, qtxmlpatterns started already
[13:17] <sergiusens> didrocks, hey, for new packages that would be handled by ci train; how do we do the ffe?
[13:18] <didrocks> sergiusens: it's packages that are new to the archive?
[13:18] <sergiusens> didrocks, yup
[13:18] <sergiusens> didrocks, media-hub to be specific
[13:18] <sergiusens> and this is also a request to get that in :-)
[13:20] <didrocks> sergiusens: it needs a regular FFe, then, we just handle it as any new package (so either an empty MP to get it landing or an existing one)
[13:20] <didrocks> sergiusens: you can file the request first in, but please add to the comment that it needs the FFe to be acked
[13:26] <didrocks> tvoss: you can merge and clean btw
[13:26] <tvoss> didrocks, okay
[13:52] <cjwatson> Mirv: https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+build/5798790 looks like a proposed-migration blocker
[13:52] <plars> didrocks: we have an issue with the ubuntuuitoolkit tests - on mako there seems to be an issue where it sometimes runs forever (until the job times out after 300 min)
[13:52] <didrocks> plars: oh, interesting, we didn't get any change on the toolkit for that. Is that quite new?
[13:52] <didrocks> bzoltan1: you may have some people too look at that ^
[13:53] <plars> didrocks: ah, wait
[13:53] <plars> didrocks: maybe a false alarm - it looks like it's still on just the custom image
[13:53] <plars> didrocks: for a second I saw that mako was still running and thought we were seeing the same thing on the regular images
[13:55] <didrocks> interesting…
[13:55] <didrocks> plars: keep us posted :)
[13:55] <plars> cwayne was looking into it on custom but if anyone has ideas, could probably use some help
[13:55] <tvoss> didrocks, can I just press merge and clean in the silo?
[13:57] <bzoltan1> didrocks:  let me look at it
[13:57] <didrocks> tvoss: yeah
[13:58] <didrocks> bzoltan1: apparently, cwayne will be your best contact :)
[13:58] <tvoss> didrocks, without setting any options I assume?
[13:58] <bzoltan1> plars: please ping me and paste the logs if you suspect the ui toolkit doing something wromg
[13:58] <didrocks> tvoss: right, no option
[14:05] <cjwatson> Mirv: http://paste.ubuntu.com/7067776/ should fix https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+build/5798788, or at least move onto the next thing - not a proposed-migration blocker but would be awfully nice
[14:07] <Mirv> cjwatson: there was a recent 5.0.2 patch that didn't apply but it seems it can be made to apply.
[14:07] <Mirv> cjwatson: this applies http://pastebin.ubuntu.com/7067786/
[14:08] <Mirv> cjwatson: so maybe I'll apply both?
[14:11] <cjwatson> Mirv: aarch64.patch already has a definition of WTF_CPU_ARM64 (you could pick either but there's no reason to change the existing patch really)
[14:12] <cjwatson> Mirv: and I think it's probably better to match the style of the code the patch would be applying to, which is all __foo__ macros rather than CPU(foo)?
[14:12] <cjwatson> Mirv: it's certainly the same idea though
[14:12] <cjwatson> Mirv: if qtwebkit doesn't have that yet, it'll probably need it too, though
[14:13] <cjwatson> I suppose you might need to care about CPU(ARM64) vs. CPU(AARCH64) if that's exported to other packages; I don't know whether that's so
[14:14] <cjwatson> doesn't really matter which, pick one :-)
[14:21] <Mirv> cjwatson: which aarch64.patch already has WTF_CPU_ARM64? so what I pasted is from https://launchpad.net/ubuntu/+source/qtscript-opensource-src/5.1.1+dfsg-2ubuntu1~really5.0.2+dfsg-3ubuntu1 modified to apply to 5.2.1 qtscript
[14:21] <cjwatson> Mirv: the one you currently have in qtbase
[14:22] <cjwatson> Mirv: sorry, in qtdeclarative
[14:22] <cjwatson> which I ported over from webkitgtk
[14:22] <cjwatson> we've apparently used different names in different places, shrug
[14:22] <Mirv> oh, there!
[14:22] <Mirv> right
[14:23] <cjwatson> probably ought to be consistent within qt* at least :)
[14:23] <Mirv> cjwatson: another problem is that qtdeclarative failed to build on arm64, which wouldn't be a problem otherwise but it's nowadays required by qttools which did build on arm64 before..
[14:24] <davmor2> didrocks: things look okay on the n7 I still need to get my n4 unlocked and it looks like the first of the people who maybe able to help me is now online
[14:25] <cjwatson> Mirv: that was what I gave you the patch above for, http://paste.ubuntu.com/7067776/
[14:25] <didrocks> davmor2: excellent! good luck and cross fingers :p
[14:25] <pmcgowan> didrocks, are you considering a change to the landings order given Qt is still getting fixes
[14:26] <didrocks> pmcgowan: you mean, order like 1, 2… 3 or anything else?
[14:26] <Mirv> cjwatson: ahah, I mistakenly thought it was reated to qtscript first you mentioned earlier. ok, let's see.
[14:26] <pmcgowan> didrocks, like landing mir and scopes before qt for example
[14:26] <didrocks> pmcgowan: basically everything that are not in Qt "lock list" can enters
[14:26] <pmcgowan> didrocks, cool
[14:26] <didrocks> pmcgowan: Mir will be blocked I guess because of unity-mir though
[14:27] <didrocks> (it's in the Qt lock list IIRC)
[14:27] <pmcgowan> maybe it can get unlocked for the time being
[14:27] <didrocks> pmcgowan: totally fine with that, it's just a rebuild for Qt?
[14:27] <didrocks> Let me check
[14:27] <pmcgowan> not sure
[14:27] <cjwatson> I might try another click landing to get a bit more of libclick (manifest extraction and the supported framework stuff)
[14:27] <cjwatson> squeezing that in before Qt would be good
[14:27] <pmcgowan> that would be good
[14:27] <pmcgowan> +1
[14:29] <didrocks> pmcgowan: ok, so unity-mir is just a rebuild
[14:29] <didrocks> pmcgowan: we can easily stick it out, get Mir landing and stick it back
[14:29] <pmcgowan> didrocks, great
[14:29] <didrocks> just Mirv needs to do a manual tracking to remember to rebuild it once Mir is in :)
[14:29] <pmcgowan> yep
[14:29] <pmcgowan> we did that with eds the other day as well
[14:30] <didrocks> yeah, that's easy to do, just need to not forget about it in the bazillon packages :)
[14:31] <didrocks> kgunn: you want to make a Mir landing tentative?
[14:32] <kgunn> didrocks: yes!
[14:32] <kgunn> thankyou!
[14:32] <didrocks> kgunn: the line request is up to date?
[14:33] <didrocks> Mirv: mind if I remove unity-mir from you, as discussed? ^
[14:33] <ogra_> [14:33] <ogra_> (now including all arches etc)
[14:34] <pmcgowan> nice
[14:34] <didrocks> ogra_: great!
[14:34] <ogra_> so the long tarball genersation due to the diff being gigantic after two weeks was the issue
[14:34] <ogra_> it caused some "stepping on my own toes" in the tools
[14:35] <balloons> wahoo!
[14:35] <didrocks> kgunn: ready is set to "No", on purpose?
[14:37] <davmor2> \o/ \o/ \o/
[14:39] <sil2100> \o/
[14:39] <didrocks> Mirv: unconfigured unity-mir then
[14:40] <didrocks> ah, will need to unconfigure u-s-c as well
[14:44] <didrocks> sil2100: Mirv: ok, I unlocked unity-mir and unity-system-compositor Qt 5.2 landing. I kgunn ack the Mir landing line, please assign to him
[14:44]  * didrocks is going for a run now
[14:49] <kgunn> didrocks: sorry...was in a meeting
[14:49]  * kgunn looks to catchup
[14:49] <rsalveti> popey: have a bug number for the emulator issue?
[14:49] <rsalveti> popey: downloading the latest and will check
[14:49] <popey> rsalveti: tried multiple times and got black screen first few times then it worked the last time annoyingly
[14:49] <kgunn> didrocks: fixed the sheet
[14:53] <rsalveti> popey: alright, guess just the usual issue with qemu not bringing up everything sometimes
[14:54] <rsalveti> cjwatson: Mirv: not sure if helps, but marcin had a few arm64 patches for qt5.2 as well: https://bugzilla.redhat.com/show_bug.cgi?id=1056051 https://bugzilla.redhat.com/show_bug.cgi?id=1056071 https://bugzilla.redhat.com/show_bug.cgi?id=1056160
[14:56] <cjwatson> probably similar/overlapping
[14:57] <rsalveti> yeah, at least the last 2 are already upstream as well
[14:58] <sil2100> didrocks: ok
[15:03] <rsalveti> davmor2: popey: did we have a bug for the delay when enabling/disabling speaker mode?
[15:03] <rsalveti> sil2100: didrocks: thanks for creating the silo for 46 btw
[15:03] <kgunn> Mirv: sil2100 ...can you reconfig silo2 ? i add one more MP back into the list
[15:04] <sil2100> kgunn: ok
[15:04] <sil2100> rsalveti: no problem
[15:05] <davmor2> popey: did we modify your original sound loud speaker doesn't work bug?
[15:05] <sil2100> kgunn: can I reconfigure already or are you still adding?
[15:05] <kgunn> sil2100: yeah, sorry, just hit enter...now try :)
[15:05] <popey> davmor2: my what?
[15:06] <sil2100> ;)
[15:07] <davmor2> popey: you filed a bug for loud speaker not working did we modify that when both of us got it to work but delayed?
[15:07] <popey> pass
[15:08] <pmcgowan> davmor2, there is a bug on the delay, forget against which package
[15:08] <davmor2> rsalveti: ^
[15:08] <davmor2> pmcgowan: thanks I thought there was too :)
[15:08] <rsalveti> pmcgowan: remember the number?
[15:09] <pmcgowan> rsalveti, not off hand, I can look
[15:09] <davmor2> rsalveti: more than 1, less than a billion, does that help lower it down?
[15:09] <rsalveti> davmor2: not much lol
[15:10] <pmcgowan> rsalveti, davmor2 https://bugs.launchpad.net/dialer-app/+bug/1277765
[15:10] <rsalveti> pmcgowan: awesome, thanks
[15:11] <davmor2> pmcgowan: thanks
[15:37] <rsalveti> pmcgowan: davmor2: popey: mind help testing https://launchpad.net/~ci-train-ppa-service/+archive/landing-001/ ? (alsa-lib, fix the delay when enabling/disabling speaker-mode)
[15:37] <rsalveti> didrocks: sil2100: guess I also need someone from the ci team to give it a try as well :-)
[15:38] <davmor2> rsalveti: I'm working on my issue with mir right now.
[15:40] <cjohnston> /3/17
[15:44] <sil2100> rsalveti: what's up?
[15:44] <sil2100> rsalveti: the alsa one?
[15:44] <sil2100> :)
[15:48] <rsalveti> sil2100: yes
[16:00] <bregma> sil2100, could I get a silo for line 42 please?
[16:01] <sil2100> bregma: let me take a look
[16:02] <seb128> bregma, sil2100: you probably want "gnome-screensaver" in the column G
[16:23] <sil2100> bregma: is the FFe accepted? Can you point me to the bug?
[16:26] <cjwatson> Mirv: at least qtdeclarative is down to tedious symbols stuff now ...
[16:26] <cjwatson> so close :)
[16:29] <bregma> sil2100, FFe bug is https://bugs.launchpad.net/unity/+bug/1282798
[16:30] <bregma> being review still, obviously we won't land the silo before it's approved
[16:33] <sil2100> bregma: right, I didn't see a Triaged yet
[16:33] <sil2100> bregma: is it important that we have it built for the FFe to be reviewed?
[16:35] <bregma> sil2100, better to ask Laney
[16:35] <Laney> You can build it, that allows for testing
[16:36] <Laney> just don't put it in trusty
[16:36] <sil2100> Laney, bregma: I'll assign a silo and mention it in the comment
[16:40] <sil2100> Damn, good that CITrain is smart!
[16:41] <kgunn> sil2100: hey...would you be the right person to approve/add...the following
[16:41] <kgunn> http://summit.ubuntu.com/uds-1403/kgunn72/meetings
[16:42] <sil2100> Oh, shock, it seems I do have the power
[16:48] <sil2100> bregma: assigned a silo, you can build ;)
[16:49] <rsalveti> pmcgowan: sil2100: landing 46 (https://launchpad.net/~ci-train-ppa-service/+archive/landing-001) is working as expected, would just like someone else to give it a try before getting it published (as we're in degraded mode)
[16:49] <sil2100> rsalveti: upgrading on my device
[16:49] <rsalveti> great
[17:00] <sil2100> rsalveti: did most of the testing from the testing plan and I think it seems ok
[17:00] <popey> didrocks: "You're not allowed to join this video call."
[17:01] <ogra_> popey, use the right account then :P
[17:01]  * ogra_ has to wrangle with that once a week 
[17:01] <popey> i am
[17:01] <didrocks> weird…
[17:01] <popey> i use two browsers
[17:01] <rsalveti> sil2100: great, can we land it already? or should we wait
[17:02]  * popey invited himself to the meeting
[17:04] <davmor2> didrocks: https://bugs.launchpad.net/mir/+bug/1290416
[17:07] <rsalveti> davmor2: wonder if this might be the issue that was fixed for mwc
[17:07] <rsalveti> kgunn: should know more
[17:07] <rsalveti> but I know we had a screen freeze there as well
[17:08] <sil2100> rsalveti: oh, you forgot to push 'build' with 'watch only' for the silo ;)
[17:08] <sil2100> rsalveti: want me to do that?
[17:10] <kgunn> davmor2: mir hasn't changed since ~Feb20
[17:10] <kgunn> davmor2: does your image include Qt5.2 ?
[17:10] <kgunn> (sorry i need a decoder ring :)
[17:10] <davmor2> kgunn: no
[17:11] <davmor2> kgunn: kdub and AlbertA are happy that they have starting point on that bug now
[17:12] <kgunn> ack...
[17:12] <davmor2> kgunn: this has only been happening since R226
[17:12] <davmor2> kgunn: which is the promoted image from Friday
[17:13] <kgunn> davmor2: hmmm...what was big landing there ? anyone know ?
[17:14] <davmor2> kgunn: pretty much everyone now but I've not long finished adding all the debug stuff to the bug for your guys to work with :)
[17:14] <ogra_> plars, could someone look at the messaging-app tests on the tablets ? it looks like ofono-phonesim is not installed when they run
[17:14] <davmor2> kgunn: hence giving didrocks the bug number for the daily release report ;)
[17:15] <kgunn> davmor2: ack...just trying to square what you are describing as a "mir regression"..but we haven't released a new mir :)
[17:16] <kgunn> AlbertA: kdub ^
[17:16] <sil2100> rsalveti: I'll do it then and publish
[17:16] <davmor2> kgunn: no not a regression but it has only been noticeable since R226  :)
[17:16] <AlbertA> kgunn: yeah it's still 0.1.5
[17:17] <AlbertA> kgunn: areas of suspect from the logs are snapshooting
[17:17] <AlbertA> kgunn: and a possible deadlock during sessionDestroyingSurface
[17:18] <kgunn> AlbertA: ah...so this is the old mwc bug
[17:19] <AlbertA> kgunn: oh this was known?
[17:20] <kgunn> AlbertA: yeah...but just hung up on "process" itself :)...its fixed on dev
[17:20] <davmor2> kgunn: ah cool :)
[17:24] <bregma> sil2100, I don't see a silo for line 42 no matter how many times I refresh, did I miss something?
[17:28] <robru> kgunn, just checking in. I'm all yours for the next 8 hours if you need any help with the Mir landing.
[17:29] <kgunn> robru: thanks...working on damn mp conflicts now!...arg
[17:29] <robru> kgunn, yeah, i noticed that ;-)
[17:34] <sil2100> didrocks: ok, so it seems cyphermox freed the silo
[17:34] <sil2100> bregma: ^
[17:34] <didrocks> sil2100: yeah, what I told you, I guess he did this because of the unack FFe
[17:34] <sil2100> cyphermox: so, Laney as the reviewer of the FFe approved the assignment of the silo for testing purposes
[17:35] <Laney> haha
[17:35] <Laney> I don't want to be known as 'the reviewer' please
[17:35] <sil2100> cyphermox: I made the comment red to make sure it doesn't land before ACKing the FFe itself
[17:35] <Laney> anyone on the RT can look at any request
[17:35] <Laney> I just think it's sensible to be able to test it
[17:35] <sil2100> Laney: ok ;) But I saw you being the most active on that bug
[17:36] <cgoldberg> robru, cyphermox, any chance of getting a silo allocated for line 47 today? (Autopilot)
[17:36] <sil2100> cyphermox, didrocks: you think we can re-add that silo, or you want to leave it unassigned?
[17:36] <cgoldberg> i was unable to make landing meeting earlier
[17:36] <robru> cgoldberg, I can assign it
[17:36] <sil2100> It's fine either way for me, but as Laney mentioned, it might be easier to test for people actually
[17:37] <cgoldberg> robru, great thanks
[17:37] <didrocks> sil2100: please readd
[17:37] <didrocks> robru: try to decouple the Mir and autopilot landing please
[17:37] <robru> didrocks, yes ;-)
[17:37] <didrocks> like having an image just with one, and an image with the other
[17:37] <didrocks> thanks!
[17:38] <robru> cgoldberg, yeah, I have to try not to land mir and autopilot too close together
[17:38] <didrocks> cgoldberg: I don't think autopilot-qt though
[17:38] <didrocks> cgoldberg: remember that both autopilot and autopilot-qt were reverted
[17:38] <robru> cgoldberg, ok you got silo 5, please build
[17:38] <didrocks> due to the regression
[17:38] <didrocks> are they fixed?
[17:38] <sil2100> cyphermox: ^ please don't unassign for now ;)
[17:39] <cgoldberg> didrocks, yes afaik
[17:39] <didrocks> cyphermox: apparently, the release team wants to test built packages before +1 or -1
[17:39] <didrocks> cgoldberg: so, why autopilot-qt isn't part of the landing?
[17:40] <cgoldberg> didrocks, one sec.. let me go through email and see whats up with autopilot-qt
[17:40] <didrocks> robru: please don't release before this is cleared out ^
[17:40] <robru> didrocks, ok. i plan to do mir first anyway
[17:41] <sil2100> bregma: the silo is back - silo 008 now
[17:41] <sil2100> Ok guys, I drive home now - see you around!
[17:41] <robru> sil2100, good night!
[17:41] <didrocks> see you sil2100 :)
[17:45]  * didrocks waves good evening as well now
[17:45] <didrocks> cgoldberg: keep us posted on the ML as well (the whole LT)
[17:45] <didrocks> thanks
[17:54] <rsalveti> kgunn: davmor2: it's probably related with 4.4
[17:54] <rsalveti> kgunn: that's why I said it should be similar with the issue we had with the mwc demo image
[17:55] <rsalveti> so the only thing that changed is the hwcomposer
[17:55] <rsalveti> as it's using a different version now, so mir might still have issues with it (hwcomposer 1.2)
[18:02] <sergiusens> robru, can I get a silo for l50?
[18:03] <robru> sergiusens, sure
[18:03] <davmor2> rsalveti: that's fine if there is already a fix that is awesome :)
[18:04] <davmor2> rsalveti: if all my logs and everything provided was confirmation that the bug is the same then it doesn't feel like a complete waste of a day :)
[18:04] <robru> sergiusens, ok, you got silo 9, please build
[18:04] <rsalveti> davmor2: sure
[18:04] <sergiusens> ty
[18:05] <robru> you're welcome!
[18:09] <sergiusens> robru, one more for l51 if you don't mind
[18:10] <robru> sergiusens, is the py3 stuff backwards compatible? or are you breaking py2 there?
[18:10] <sergiusens> robru, it's backwards compatible
[18:10] <robru> sergiusens, great ;-)
[18:11] <sergiusens> robru, but; that's why we need to run agains everything currently under the ci image test anyways to make sure
[18:11] <robru> sergiusens, right
[18:11] <robru> sergiusens, ok, you got silo 10, please build
[18:11] <sergiusens> I intend to ping doanac` for that; tsk :-)
[18:12] <robru> seb128, do you need me to publish silo 7? I forget if you can publish or not
[18:12] <seb128> robru, just did, thanks
[18:12] <robru> seb128, great
[18:14] <davmor2> psivaa, plars: you guys around now?
[18:14] <psivaa> davmor2: hello
[18:15] <plars> davmor2: yes
[18:15] <davmor2> psivaa, plars: If you are both about could we have a 5 minute hangout?
[18:15] <plars> sure
[18:16] <davmor2> psivaa, plars: https://plus.google.com/hangouts/_/7ecpj08l3ar12lr9julchs3cvc?hl=en-GB
[18:17] <plars> davmor2: it says I'm not allowed to join
[18:17] <davmor2> plars: it's a canonical one
[18:18] <kgunn> sorry...had some internet monkey biz... davmor2 kdub AlbertA rsalveti ...the free bug is this one, and has a fix in 0.1.6...which i'm trying to land right now
[18:18] <kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1281728
[18:18] <plars> davmor2: I'm logged into two accounts - it's never been a problem before though
[18:18] <davmor2> plars: :(
[18:19] <davmor2> psivaa: is in so I don't know what the issue is
[18:19] <davmor2> plars: ^
[18:19] <plars> davmor2: give me a sec
[18:19] <davmor2> kgunn: fantastic so when the new version lands everythign should be back to normal then right?
[18:20] <plars> davmor2: can you invite me?
[18:20] <kgunn> davmor2: unless its a new bug...in which case all my wonderings about no-new-mir are meaningful :)
[18:22] <rsalveti> kgunn: are we still trying to land mir before qt 5.2?
[18:22] <kgunn> rsalveti: so i have mir building in silo 002 atm
[18:23] <kgunn> i know 5.2 is special...so not completely sure how to answer your question :)
[18:23] <robru> rsalveti, oh yes, the plan is to land mir today, and qt5.2 "sometime this week" (when it's ready)
[18:24] <kgunn> robru: so..i just lost console on silo002....but i assume the build is still going ?
[18:24] <kgunn> clicking on console view give me a "service temporarily unavailable"
[18:24] <sergiusens> robru, I just got a 503 from jenkins/train, is it only m?
[18:24] <robru> kgunn, dear god...
[18:24] <sergiusens> ah
[18:25] <sergiusens> not only me then...
[18:25] <robru> kgunn, your builds are still here: https://launchpad.net/~ci-train-ppa-service/+archive/landing-002/+packages
[18:25] <rsalveti> great then
[18:25] <robru> not sure where jenkins wentthough
[18:25] <robru> cyphermox is the only person who has the access to fix this at this time of day.
[18:27] <sergiusens> doanac`, can you run https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=28 with utah/ci?
[18:29] <doanac`> sergiusens: ack.
[18:31] <sergiusens> doing the same, but without utah
[18:31] <kgunn> robru: so...looks like none of those packages actually published
[18:31] <kgunn> failed on dep waits...
[18:31] <robru> kgunn, amazing
[18:32] <robru> kgunn, how did they both fail? the ppa build should not be affected by jenkins going down (jenkins just monitors the builds, they are standard PPA builds handled by launchpad)
[18:32] <doanac`> sergiusens: NOTE: we aren't using utah for touch testing anymore, but i'm still running it through our ci scripts here: http://q-jenkins:8080/job/andy-smoke-daily-test/3/console
[18:34] <kgunn> robru: gotta run for lunch...bbiab
[18:35] <sergiusens> doanac`, oh, interesting; thanks for the detail
[18:36] <robru> kgunn, so lp:mir never got uploaded to the silo.
[18:38] <robru> kgunn, and therefore everything that depended on it is stuck in depwait
[18:39] <robru> kgunn, i am literally powerless to fix this until cyphermox gets here to reboot jenkins. he just told me he'll be available in a few minutes though
[19:04] <cyphermox> just started jenkins
[19:05] <cyphermox> sorry, I was stuck in traffic
[19:06] <cyphermox> robru: kgunn: jenkins is back up
[19:17] <robru> cyphermox, thanks
[19:21] <robru> kgunn, i started a rebuild for you
[19:31] <thomi> robru: cyphermox: are one of you two gentlemen able to explain to me why this build job failed please? http://162.213.34.102/job/landing-005-1-build/57/console
[19:31] <robru> thomi, checking
[19:31] <thomi> There's a 'warning' message at the end of the console, but since it's a warning (and not an error) I'm not sure if that's why the build failed
[19:31] <thomi> also, the message doesn't make sense to me at all
[19:32] <thomi> I think maybe it's due to didier's reverting the package in distro
[19:32] <robru> thomi, yep, that warning is exactly why it failed.
[19:32] <robru> thomi, and also yes, a revert in distro would cause that.
[19:32] <thomi> ok - that message *really* should be an error then... but anyway... how do I fix it?
[19:32] <robru> thomi, so what you need to do is grab the debian/changelog from distro and just copy that changelog entry into one of the MPs for the project, then once changelog matches distro then the build will proceed
[19:33] <thomi> robru: OK, gotchya, thanks.
[19:33] <robru> thomi, you're right though, it's weird that it's just a warning but then it fails on that... should be an error
[19:33]  * thomi adds this bit of information to his ci-train manual
[19:35] <robru> rsalveti, seb128 : hope I'm not stepping on your toes but I merged silos 1, 3, and 7 for you.
[19:35] <rsalveti> robru: that's fine, thanks
[19:37] <robru> sergiusens, status is wrong in spreadsheet, silos 9 and 10 are both done building if you want to start testing
[19:39] <sergiusens> robru, yeah, started a bit back when I saw the ppa finished buildinf :-)
[19:39] <sergiusens> thanks btw
[19:39] <robru> sergiusens, you're welcome
[19:40] <robru> ok, everything looks good for now as far as I can tell, I'm going to take lunch, should be back within an hour, feel free to ping me if you need anything.
[19:57] <seb128> robru, that's ok, thanks
[19:59] <popey> 36
[19:59] <popey> bah
[20:00] <bregma> rsalveti, I need someone to upload a package to a silo and it looks like you're the only one around who can help at the moment ... willing?
[20:00] <rsalveti> bregma: sure, what's up?
[20:01] <bregma> rsalveti, I need http://people.ubuntu.com/~3v1n0/Lockscreen-GS/ uploaded to ppa:ci-train-ppa-service/landing-008 (after properly setting the release in d/changelog) if you could
[20:03] <rsalveti> bregma: sure, 1 sec
[20:09] <rsalveti> bregma: building
[20:12] <bregma> rsalveti, thanks
[20:24] <bregma> robru, cyphermox, could I get a silo assigned to line 52 please?
[20:24] <cyphermox> most certainly sir
[20:28] <cyphermox> bregma: landing-001
[20:28] <bregma> woo hoo, thanks
[20:54] <robru> ok, i'm back for landings now
[20:58] <robru> kgunn, just checking on mir, looks like the last rebuild i started failed due to a bunch of depwaits, but the good news is that mir itself got uploaded and built successfully. I suspect if we just force yet another rebuild, it should all work.
[20:59] <kgunn> robru: yep...or target build unity-mir, papi, usc
[20:59] <robru> kgunn, right, we should start target building mir first ;-)
[21:00] <kgunn> robru: yeah...its weird, i thot it should do it all in order of the MP's
[21:00] <kgunn> e.g. mir mp is first
[21:02] <robru> kgunn, yeah, i thought that was the case as well, but when I looked deeper into it, it seems to only respect the order within projects (eg, multiple MPs against papi will get merged in the right order) but the actual order of projects is completely arbitrary. not even alphabetical, it looks like they're stored in a python dict and then uploaded in python-dict-access-order, which is essentially unpredictable
[21:16] <dobey> seems like something needs to apply all the patches to everything in the silo, then generate a package build dependency graph, get the source package for each binary bulid-depends, and see if it is one of the things in the silo, and build things in the silo in the appropriate order according to the dep chain
[21:16] <dobey> but that is incredibly complex to do :)
[21:41] <robru> dobey, yeah, easier would be if it just built them in the damn order that we put the MPs ;-)
[22:13] <robru> kgunn, how's testing mir going? need a hand?
[22:14] <kgunn> robru: was just about to begin...but yeah, if you're interested...
[22:14] <robru> kgunn, yeah ;-)
[22:14] <robru> kgunn, so I just installed the silo contents on my mako, rebooted, and it won't boot. somewhat troubling...
[22:14] <kgunn> robru: hmmm...that is no good...
[22:14]  * kgunn gets a little worried
[22:14] <robru> kgunn, just gets stuck at the 'Google' screen with the little unlock icon
[22:17] <robru> kgunn, hummm, reflashing didn't fix it. bootstrapping now
[22:17] <robru> kgunn, any luck on your end?
[22:26] <bregma> robru, do me a favour and find a silo for line 53 when you get the chance?
[22:26] <robru> bregma, webapps? my pleasure!
[22:27] <robru> bregma, ok, you got silo 3
[22:27] <bregma> thanks muchly
[22:27] <robru> you're welcome!
[22:30] <robru> kgunn, is it possible that simply installing all binary packages present in the silo can result in a broken system? is there a certain subset of packages I should be installing in order to test this properly?
[22:31] <kgunn> robru: so you do have to have all those packages together for sure
[22:31] <kgunn> robru: i gotta run... i forgot about family dinner...bbiab...
[22:32] <robru> kgunn, ok, i'll keep poking at it
[22:32] <robru> kgunn, I'm gonna take a wild guess and say that installing ubuntu-desktop-mir on the phone was probably a mistake ;-)
[22:40] <robru> kgunn, hummm, now I can get past the Google screen, but it just boots into a black screen now. pressing the power button visible toggles from "screen on but black" vs "screen off". can't get unity8 to appear
[22:43] <robru> kgunn, ping me when you're back. not sure how to proceed
[22:53] <doanac`> sergiusens: here are the results from running that phablet-tools branch: http://q-jenkins:8080/job/andy-smoke-daily-test/3/#showFailuresLink
[22:53] <sergiusens> doanac`, yeah, was just seeing them
[22:54] <doanac`> not sure which failures you expected and which you didn't. music app seems to not have run at all
[22:54] <sergiusens> doanac`, calendar is expected; I forgot we needed a new image build for that
[22:54] <sergiusens> doanac`, and gallery unexpected but easy to fix in any case
[22:54] <doanac`> sergiusens: great. let me know, and I can re-run for you any time
[22:54] <sergiusens> doanac`, thanks, and will do!