[05:24] <Mirv> hmm why does my updated mako just flickr and crash unity8...
[05:36] <Mirv> (54)
[07:07] <didrocks> hey Mirv, how was your week-end?
[07:27] <Mirv> hi didrocks, fine (and long!)
[07:27] <didrocks> heh, I hope you enjoyed your Friday!
[07:27] <didrocks> did you go outside?
[07:27] <didrocks> like, were they fireworks and such?
[07:30] <Mirv> I did go outside, but not that far away. there aren't permissions for "fireworks at will" (like in the New Year), so there would have been only some in some more official festivities places.
[07:31] <didrocks> yeah, I guess so… ;)
[07:33] <didrocks> Mirv: did you suffer from issues with latest upstart-app-launch?
[07:33] <didrocks> Mirv: there is an ABI transition, so it should have picked other packages as well
[07:37] <Mirv> didrocks: so it seems I have some other problem, I just have unity8 flickering and crashing when I try to open it.
[07:37] <Mirv> even after I downgraded the upstart-app-launch
[07:37] <Mirv> and yes upstart-app-launch has the bump now
[07:39] <Mirv> maybe a time for phablet-flash -b to be sure I'm seeing this on image 54
[07:41] <didrocks> Mirv: yeah, sounds like a phablet-flash -b time :)
[07:41] <didrocks> can you keep me posted?
[07:41] <didrocks> Mirv: FYI, I just reuploaded an url-dispatcher for the soname libupstart change
[07:41] <didrocks> Mirv: we don't want the hazardous commit in :)
[08:53] <Mirv> ok full flash seems to fix whatever problem I had
[08:56] <sil2100> Mirv: ok, good to know - my device is still flashing
[08:58] <didrocks> FYI, I've uploaded url-dispatcher from sil2100's branch and disabled automatic rebuilds
[08:59] <sil2100> didrocks: thanks!
[08:59] <sil2100> didrocks: hm, maybe we should change the driver of content-hub btw.?
[08:59] <sil2100> didrocks: since from what I see only Ken has the power to top-approve there right now, which is tragic ;/
[08:59] <didrocks> sil2100: yeah, sounds legit, we will need to ping Ken for it
[09:14] <sil2100> didrocks: do you think it would be wise to switch the driver now to phablet-team (for now), I can do the switch and move trunk to that team so we can approve the ted's branch
[09:22] <didrocks> sil2100: that would be good, but we need Ken to change the driver
[09:22] <sil2100> didrocks: why? I see I can do that as well on LP, strangely
[09:23] <didrocks> sil2100: oh, if you can, please do then :)
[09:25] <Mirv> sil2100: didrocks: if I recall correctly, the driver doesn't actually matter that much, the only thing that matters is that under which user/team the trunk branch is set to be pushed
[09:26] <didrocks> Mirv: yeah, I guess it is the case
[09:26] <sil2100> didrocks: I re-target ted's branch in a moment as well!
[09:27] <didrocks> great ;)
[09:28] <sil2100> didrocks: can you approve? Would feel silly to do it myself ;p https://code.launchpad.net/~ted/content-hub/ual2/+merge/198210
[09:29] <didrocks> done
[09:38] <Mirv> sil2100: I can also run all of the upstart-app-launch tests if you have other stuff to do, since I'm relatively far already
[09:39] <sil2100> Mirv: my device is free right now, so if there are some big tests that you still didn't run, I can pick those up
[09:40] <popey> didrocks: FOUND IT!
[09:40] <popey> https://bugs.launchpad.net/unity-mir/+bug/1234538
[09:40] <didrocks> popey: ok, sounds like the same bug that is getting to be fixed by upstart-app-launch, let's cross fingers :)
[09:40] <Mirv> sil2100: well click tests are todo, there are some slow ones there.. dropping_letters_app ubuntu_rssreader_app calendar_app music_app ubuntu_terminal_app ubuntu_clock_app ubuntu_calculator_app ubuntu_weather_app ubuntu_filemanager_app ?
[09:40] <Mirv> I'm running unity8 + webbrowser, they're quite slow
[09:40] <popey> bug 1243665 also related
[09:41] <popey> so yeah
[09:41] <popey> hope so
[09:41] <Mirv> all others run so far
[09:41] <sil2100> Mirv: ok, then I'll prepare for some click-package testing to make things move faster
[09:43] <Mirv> updating landing plan as I go
[10:07] <sil2100> Mirv: doing the same, working now on calendar-app
[10:14] <sil2100> hmmm, many calendar-app failures, re-running to make sure what's up
[10:22] <Mirv> sil2100: I've now finished running all except those click tests I listed. so when/if you're happy with your results (compared to the dashboard), feel free to publish
[10:22] <Mirv> sil2100: I tend to re-run those single failing tests to see if they work alone
[10:22] <sil2100> Mirv: could you run calendar-app tests on your device?
[10:22] <Mirv> instead of rerunning the whole suite over and over
[10:22] <Mirv> sil2100: ok, doing in a moment
[10:23] <sil2100> Mirv: yes, but here I get 14 failures, that's like almost all tests
[10:32] <sil2100> Mirv: all the other tests look good so far
[10:33] <sil2100> Mirv: hm, filemanager also resulted with a lot of tests
[10:33] <sil2100> Mirv: it looks to me that sometimes it is unable to start the app for testing, resulting with only a white screen instead of the application
[10:34] <sil2100> Mirv: do you have the same on your device?
[10:34] <sil2100> Re-running the test usually fixes the issue
[10:35] <sil2100> Not sure if this can be upstart related?
[10:35] <sil2100> didrocks: ^
[10:36] <sil2100> The tests are then failing with: "RuntimeError: Could not find autopilot interface for click package 'com.ubuntu.filemanager_filemanager_0.1.1.95' after 10 seconds." and there is a white screen on my device
[10:40] <didrocks> sil2100: really weird, doesn't sounds like upstart, right?
[10:40] <didrocks> sil2100: did you try to downgrade?
[10:41] <sil2100> didrocks: yes, running the tests with content-hub downgraded, should have results soon
[10:41] <sil2100> I mean
[10:41] <sil2100> upstart
[10:41] <sil2100> ....
[10:45] <Mirv> sil2100: I got only 2 failures in calendar-app
[10:46] <sil2100> Ok...
[10:47] <Mirv> sil2100: and no I haven't seen white screen instead of application kind of thing. now running filemanager.
[10:47] <Mirv> I simply ran phablet-config autopilot --dbus-probe enable + phablet-click-test-setup + phablet-test-run now for these click tests
[10:47] <sil2100> Mirv: I see it's unrelated, with downgraded upstart I see the same ;/
[10:48] <sil2100> Mirv: I would say, let's release
[10:49] <Mirv> sil2100: well I'll run this test still and since everything seems to be fine at here end, I'll release after that?
[10:49] <sil2100> Indeed :) Thanks! I wonder what's up with my device, I'll try a reboot and try then
[11:05] <didrocks> Mirv: did the tests pass?
[11:08] <sil2100> Mirv: are we ready with everything now? I guess all other tests went fine here, not counting those times I had to re-run in the white-screen case
[11:10] <Mirv> didrocks: 3 failures, same as #54. so publishing now.
[11:11] <sil2100> \o/ upstart-app-launch, content-hub and unity-mir + the url-handler that's in daily-release
[11:11] <sil2100> I mean
[11:11] <sil2100> url-dispatcher
[11:11] <Mirv> didrocks: or actually, after this http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Misc./job/cu2d-misc-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_upstart-app-launch_0.3+14.04.20131209-0ubuntu1.diff
[11:11] <sil2100> Damn, so many typos today...
[11:16] <didrocks> Mirv: did you check that there is no common files shipped between -1 and -2?
[11:17] <didrocks> Mirv: I'm afraid the -dev are shipping the same files without replaces:, right?
[11:17] <didrocks> oh, nm, there is the replaces
[11:17] <didrocks> Mirv: +1 then
[11:18] <didrocks> Mirv: remember that url-handler needs to be uploaded manually
[11:18] <didrocks> url-dispathcer*
[11:18] <sil2100> ;)
[11:21] <didrocks> Mirv: still around?
[11:21] <didrocks> sil2100: in case, can you publish them?
[11:21] <sil2100> didrocks: sure, what should I do with url-dispatcher though?
[11:21] <didrocks> I think we are already really late to get something promoted tonight
[11:21] <didrocks> sil2100: I'll upload it
[11:22] <Mirv> didrocks: ok, thanks, but sil2100 is apparently doing it now
[11:23] <sil2100> content-hub and unity-mir I publish as well
[11:24] <Mirv> sil2100: thanks!
[11:24] <Mirv> url-dishandler
[11:24] <sil2100> didrocks: as a formality: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Unity8/job/cu2d-unity8-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity-mir_0.2+14.04.20131209-0ubuntu1.diff and http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Services/job/cu2d-services-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_content-hub_0.0+14.04.20131209.1-0ubuntu1.diff ACKed? :)
[11:25] <didrocks> sil2100: +1
[11:26] <sil2100> Ok, published, just url-dispatcher left - but I guess didrocks has it covered already
[11:26] <didrocks> uploaded
[11:38] <didrocks> sil2100: I don't see content-hub
[11:41] <sil2100> didrocks: oh, hm, stack is red, wait
[11:41] <sil2100> Shit
[11:41] <didrocks> sil2100: can we ensure we look at the stacks when publishing them? ;)
[11:41] <didrocks> so that we don't end up in situations where things are not published
[11:41] <didrocks> (or looking at -changes)
[11:41] <sil2100> but but it rarely ever happens that suddenly cu2d reds our a force publish
[11:42] <sil2100> bzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/+branch/content-hub/" and relative path "../../../+branch/content-hub/"
[11:42] <didrocks> yeah, but better to care rather than being worry
[11:42] <Mirv> sil2100: that error is maybe because of the content-hub owner?
[11:42] <didrocks> seems like it can't merge back?
[11:42] <sil2100> Is it because of my re-targetting branch?
[11:42] <Mirv> "The lp-propose command returned an error."
[11:42] <didrocks> probably yeah
[11:42] <sil2100> Will a redeploy of the stack help?
[11:43] <didrocks> sil2100: depends, does the bot and you have access right to the redeploy one?
[11:43] <didrocks> retargeted*
[11:43] <sil2100> The retargetted one is in ~phablet-team, so it should be fine
[11:43] <didrocks> ok, so redeploy
[11:43] <didrocks> with -U
[11:43] <didrocks> not -US
[11:46] <sil2100> didrocks: if I force-publish content-hub from the stack now after the redeployment, it won't force a rebuild of the package, just push the one that's in the PPA now, right?
[11:47] <didrocks> sil2100: yep
[11:51] <sil2100> didrocks: ok, this time it went through
[11:51] <sil2100> didrocks: noting down to make sure stacks get published when publishing
[11:55] <didrocks> sil2100: thanks!
[12:06] <cjwatson> Mirv: Could you re-trigger https://code.launchpad.net/~canonical-qt5-edgers/+recipe/ubuntu-keyboard-daily-qt52 ?  I'd like to see how it gets on with the new chroot.
[12:14] <Mirv> cjwatson: retriggered... after ~15 reloads (LP timeouts on recipe pages are really bad)
[12:14] <Mirv> https://code.launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+recipebuild/603481
[12:15] <cjwatson> thanks, let's see
[12:18] <sil2100> Mirv: oh! You haunted by this as well?
[12:19] <Mirv> cjwatson: looks good now!
[12:19] <Mirv> sil2100: dejavu... :D
[12:20] <cjwatson> Mirv: excellent
[12:21] <cjwatson> so just stupid handling of forced removals of packages in the chroot, not failed :any support at all
[12:22] <Mirv> ok then. this is at a good time since I'm about to have a lot more recipe builds against Qt 5.2 right now, and others might have been affected as well.
[12:24] <Mirv> sil2100: I'd guess your similar issue might be resolved now too
[12:27] <sil2100> Mirv: yay, although it's no longer an issue, the guys found a workaround for that
[12:30] <didrocks> cjwatson: hum, I'm not really sure to understand something in the build-dep wait
[12:30] <didrocks> https://launchpad.net/ubuntu/+source/url-dispatcher/0.1+14.04.20131209.1-0ubuntu1/+build/5317569
[12:31] <didrocks> -> but rmadison libupstart-app-launch2-dev
[12:31] <didrocks> says it's published in -proposed
[12:31] <didrocks> I'm sure I'm missing an obvious typo mistake…
[12:31] <cjwatson> it's in universe
[12:31] <didrocks> oh right
[12:31] <cjwatson> url-dispatcher source is in main and can only use binaries in main
[12:31]  * didrocks promotes
[12:31] <didrocks> yeah yeah
[12:31] <didrocks> sorry for the ping
[12:31] <cjwatson> I'll move it
[12:32] <didrocks> thanks cjwatson :)
[12:32] <cjwatson> it should auto-retry (eventually)
[12:33] <cjwatson> oh dear, why the new build-dep on liblttng-ust-dev?
[12:33] <didrocks> I guess it's a question for tedg once he's around
[12:34] <cjwatson> that'll need to be made architecture-specific - see "apt-cache showsrc ust | grep ^Architecture"
[12:34] <cjwatson> (please don't make it [!arm64] - make it a subset of the positive architectures supported by ust instead)
[12:35] <didrocks> oh, so we'll have url-dispatcher blocked in proposed I guess?
[12:36] <didrocks> as it will be in dep-wait
[12:37] <cjwatson> yes
[12:39] <didrocks> cjwatson: why not this !arm64 btw?
[12:39] <didrocks> but rather listing explicitely
[12:39] <cjwatson> Two reasons
[12:39] <cjwatson> Firstly, it's silly not to use the same terms that ust itself does, since the url-dispatcher restriction is a direct consequence of the list of packages supported by ust
[12:39] <cjwatson> Secondly, we'll have another new port shortly which is also not in ust's list
[12:40] <didrocks> cjwatson: ok, I'll use the same list than for ust (including debian ones then)
[12:40] <didrocks> thanks cjwatson
[12:40] <cjwatson> It should also make it easier to visually spot discrepancies in future
[12:40] <cjwatson> (you could put a comment above it in the control file, e.g.)
[12:40] <didrocks> (already there ;))
[12:40] <cjwatson> heh, ok
[12:43] <didrocks> (uploaded)
[12:50] <didrocks> cjwatson: in fact, it's upstart-app-launch which deps on ust
[12:51] <didrocks> cjwatson: so, I just uploaded that one (in addition, to url-dispatcher)
[12:51] <cjwatson> ok
[12:51] <didrocks> what's the best way to unblock those in britney once built? I think I need to rebuild all reverse-build-deps of upstart-app-launch
[12:51] <didrocks> but should I keep them as arch: any and we remove the binaries on other archs to help britney?
[12:51] <didrocks> or should I list the arch for all of them?
[13:00] <didrocks> cjwatson: ok, I guess I'm going to list then
[13:01] <cjwatson> didrocks: I don't understand.  Why would we remove them?
[13:01] <cjwatson> Confused.
[13:02] <didrocks> cjwatson: so, upstart-app-launch is going to dep on a subset of archive it was building against before (so no arm64 for instance) because of ust
[13:02] <didrocks> I guess as the list is written in debian/control, britney will let go it through
[13:02] <cjwatson> No
[13:02] <didrocks> ah?
[13:02] <cjwatson> Why can't upstart-app-launch continue to build on arm64, just without ust?
[13:03] <didrocks> ok, for that, we'll need upstream support I guess then
[13:03] <didrocks> which is then going to block an image promotion
[13:03] <didrocks> I understood you wanted Architecture: <list>
[13:03] <cjwatson> No, I was expecting Build-Depends: liblttng-ust-dev [list]
[13:04] <cjwatson> But it's a question.  Is this truly mandatory now or can it have a sensible fallback?
[13:04] <didrocks> cjwatson: let me look at the code
[13:04] <sil2100> The new ust in the archive seems to cause some trouble for us? Or the troublesome part is the upstart dependency here?
[13:04] <cjwatson> upstart-app-launch, not upstart
[13:04] <cjwatson> Nothing to do with the new ust either
[13:04] <cjwatson> Please read the scrollback
[13:05] <sil2100> Right, by upstart I mean upstart-app-launch, just was saving up typing time
[13:05] <cjwatson> Please don't do that :P
[13:05] <sil2100> Ok, so the new dep then ;)
[13:05] <cjwatson> didrocks: if it's truly mandatory, adding an explicit architecture list achieves nothing and we should remove the binaries
[13:06] <cjwatson> didrocks: And indeed the changes you uploaded were largely pointless, I'm afraid
[13:06] <didrocks> cjwatson: it sems to me
[13:07] <cjwatson> didrocks: If you'd given me an opportunity to review the diffs :P
[13:07] <didrocks> cjwatson: it seems to be mandatory
[13:07] <cjwatson> Then it might as well just dep-wait
[13:07] <didrocks> cjwatson: well, sorry, I was assuming that britney parsed debian/control to take decisions
[13:07] <cjwatson> An explicit architecture list is just something that needs to be kept in sync in future
[13:07] <cjwatson> No, it doesn't, and this is well-documented
[13:07] <cjwatson> https://wiki.ubuntu.com/ProposedMigration gives the full list of criteria
[13:08] <didrocks> cjwatson: yeah, I read the page but didn't read back
[13:08] <cjwatson> I'd actually recommend reverting those changes again if liblttng-ust-dev is mandatory
[13:08] <cjwatson> They mean that if ust is ported to arm64 in future, url-dispatcher and upstart-app-launch will need changes in sync, while they otherwise wouldn't
[13:08] <didrocks> cjwatson: agreed, but i'll just prepare that in trunk
[13:08] <didrocks> without re-releasing
[13:08] <didrocks> if you don't mind
[13:08] <cjwatson> sure
[13:08] <didrocks> ok, so, I guess once upstart-app-launch is built, what is needed is:
[13:09] <didrocks> * promote the new binaries to main
[13:09] <didrocks> (if not done already)
[13:09] <didrocks> * removing the arm64 and powerpc?
[13:09] <cjwatson> what has powerpc got to do with anything, aside from your vendetta against it? :P
[13:09] <didrocks> * doing that removal for all deps of libupstart-app-launch*
[13:09] <cjwatson> ust builds on powerpc
[13:10] <didrocks> cjwatson: sorry, it was too much at the end of the list for my brain to catch it :)
[13:10] <didrocks> so yeah, arm64 only
[13:11] <cjwatson> I'm looking through its rdeps
[13:12] <didrocks> cjwatson: content-hub, url-dispatcher and unity-mir IIRC
[13:12] <cjwatson> ugh, painful
[13:12] <cjwatson> I'm not going to rely on memory ...
[13:12] <cjwatson> there are indicators and such too
[13:12] <didrocks> for ust itself, right
[13:12] <cjwatson> I wish upstream had discussed this with foundations first
[13:13] <didrocks> yeah, going to be painful :/
[13:13] <cjwatson> removing architectures is an annoying thing to do
[13:13] <didrocks> agreed
[13:15] <didrocks> cjwatson: can I help for anything?
[13:18] <cjwatson> don't think so, I'm just chasing the dep chain
[13:18] <didrocks> ok, revert done in trunks FYI for the arch: list thing
[13:22] <cjwatson> didrocks: there is one thing - I'm going to need to remove unity-greeter-session-broadcast/arm64, but it only has a run-time dependency on upstart-app-launch, not a build-dep
[13:23] <cjwatson> didrocks: so if I remove it it'll just reappear on the next upload
[13:23] <didrocks> cjwatson: ok, so for this one, I need to change the binary dep to list archs
[13:23] <cjwatson> didrocks: do you think it could have an artificial build-dep on upstart-app-launch instead?  that's usually better than a hardcoded arch list
[13:24] <didrocks> cjwatson: with a comment, I think that could do it, I'll get you something to review
[13:24] <cjwatson> didrocks: or maybe on a less intrusive binary package
[13:24] <cjwatson> didrocks: libupstart-app-launch2-dev?  shame there's no unversioned -dev package there
[13:24] <cjwatson> didrocks: upstart-app-launch itself is quite heavyweight for a b-d, it depends on click/click-apparmor
[13:25] <didrocks> cjwatson: yeah, I already had that discussion with tedg, hard to get them agreeing on what we need for a -dev
[13:25] <didrocks> cjwatson: ok, doing on libupstart-app-launch2-dev
[13:25] <cjwatson> ok, thanks
[13:25] <cjwatson> I've removed url-dispatcher and its rdeps
[13:25] <didrocks> thanks :)
[13:25] <cjwatson> so I think just upstart-app-launch and unity-greeter-session-broadcast are left
[13:26] <didrocks> upstart-app-launch has just been published I guess
[13:26] <didrocks> (seeing it in rmadison)
[13:26] <cjwatson> I wasn't waiting for that anyway
[13:26] <cjwatson> since I'm removing things from trusty, it doesn't matter
[13:26] <didrocks> indeed
[13:27] <cjwatson> hopefully systemtap/ust will get ported to arm64 soon - I see there's upstream work in progress on it
[13:27] <didrocks> ah, excellent, so the consideration to dep on ust will be valid or better to still chat with ted?
[13:27] <cjwatson> it's still a roadblock to new ports; I still think it should be optional
[13:28] <cjwatson> it's a heavyweight and complex piece
[13:28] <cjwatson> which is hard to port
[13:28] <didrocks> cjwatson: ok, I'm noting to talk to ted then
[13:28] <cjwatson> thanks
[13:30] <didrocks> cjwatson: how about that description? https://code.launchpad.net/~didrocks/unity-greeter-session-broadcast/add-upstart-app-launch-build-dep/+merge/198259
[14:00] <didrocks> ok, so seems the only blocker is out of date on arm64: libupstart-app-launch1, libupstart-app-launch1-dev, upstart-app-launch, upstart-app-launch-tools (from 0.3+14.04.20131126-0ubuntu1)
[14:01] <didrocks> not sure if you've done the removal or not already (maybe pending publication, but rmadison says the binaries are still around on arm64 in trusty pocket)
[14:28] <cjwatson> didrocks: r=me (for whatever that's worth)
[14:28] <cjwatson> didrocks: I haven't done the removal, am waiting for unity-greeter-session-broadcast to land
[14:29] <didrocks> cjwatson: you mean, in trunk or in archive? is that blocking? (we have an image build depending on it)
[14:29] <didrocks> cjwatson: like, if I land it in trunk, I can ensure that we are going to publish the next version with it (in tonight's landing)
[14:30] <didrocks> just want to get an image build and promoted
[14:31] <cjwatson> didrocks: trunk would be fine
[14:31] <didrocks> cjwatson: ok, I top-approved
[14:48] <didrocks> fginther: can you give a kick for https://code.launchpad.net/~didrocks/unity-greeter-session-broadcast/add-upstart-app-launch-build-dep/+merge/198259? image build is depending on that
[14:52] <didrocks> ah merged :)
[14:52] <didrocks> cjwatson: ok, so upstart-app-launch binaries and unity-greeter-session-broadcast are the last ones I guess ^
[14:52] <didrocks> (should be all good now)
[14:55] <sil2100> \o/
[14:57] <cjwatson> didrocks: removed
[14:58] <didrocks> thanks cjwatson and sorry for the trouble, I'm watching the transition and may annoy you or lool for an image build (I don't see the button on cdimage yet)
[15:00] <cjwatson> it's on iso.qa, not on cdimage
[15:03] <didrocks> cjwatson: I'll try to sync up with stgraber asap to know where this tool is
[15:03] <cjwatson> didrocks: http://iso.qa.ubuntu.com, log in
[15:03] <didrocks> (done)
[15:03] <cjwatson> should be usual sso
[15:04] <didrocks> I don't see anything
[15:04] <didrocks> You are currently on: Ubuntu ISO Testing
[15:04] <didrocks> and then, nothing
[15:04] <cjwatson> then select "Trusty Daily" on the front page
[15:04] <cjwatson> check "Ubuntu Touch armhf", scroll to the bottom, check that it says "Request a rebuild" under "Rebuilds", press "Update rebuild status"
[15:05] <didrocks> in the actions, I only have "passed with no bugs", "subscribe", "unsuscribe"
[15:05] <didrocks> I logged in checking the touch release team
[15:05] <didrocks> let me logout and retry
[15:06] <didrocks> cjwatson: confirming I don't see any Rebuilds section on http://iso.qa.ubuntu.com/qatracker/milestones/308/builds/58757/testcases
[15:08] <cjwatson> try http://iso.qa.ubuntu.com/qatracker/milestones/308/builds
[15:08] <cjwatson> you shouldn't actually *click* on Ubuntu Touch armhf
[15:08] <cjwatson> just check the checkbox beside it
[15:08] <didrocks> cjwatson: ah ok, yeah, you're right, was just one path to deep
[15:08] <didrocks> sorry for being so dummy…
[16:17] <rsalveti> didrocks: how are we in terms of merging/landing new stuff in the archive?
[16:17] <rsalveti> didrocks: are we still in a soft freeze to be able to promote an image?
[16:17]  * rsalveti wants to land a new hybris and ofono
[16:17] <didrocks> rsalveti: we are in hell :)
[16:18] <didrocks> rsalveti: yeah, I just kicked an image build, for the promotion candidate
[16:18] <didrocks> rsalveti: I would prefer before we promote it we don't take risks please
[16:18] <didrocks> we had enough collisions… :/
[16:19] <rsalveti> ok, will get the code in trunk and available in a ppa for now, will ping you again tomorrow then
[16:21] <didrocks> rsalveti: let's really cross fingers we can promote this time…
[16:21] <rsalveti> seems it's really easy to reproduce bug 1258655 with latest image
[16:22] <rsalveti> not sure if we want to fix that first before promoting a new image
[16:22] <rsalveti> it's kind of a blocker for dogfooding imho
[16:22] <rsalveti> I could get unity8 to crash a bunch of times in a row
[16:25] <didrocks> rsalveti: last comment from Saviq told it's not a regression compared to latest promoted image
[16:25] <rsalveti> didrocks: right, but it seems way easier to reproduce it now
[16:25] <rsalveti> I was using the phone for a few minutes and could make it crash a few times already
[16:25] <rsalveti> the issue was probably there already
[16:26] <didrocks> yeah, just easier to trigger hum…
[16:26] <rsalveti> but something changed with latest unity8 that made it easier to be triggered
[16:26] <didrocks> rsalveti: I would still be in favor of promoting (if the tests pass), we still have no unity8 fixes for it and have big issues unfixed in current images
[16:26] <didrocks> rsalveti: however, putting that one on top of Saviq's team list
[16:26] <didrocks> does it sound ok for you?
[16:57] <rsalveti> didrocks: yeah, can easily trigger that
[16:58] <didrocks> rsalveti: ok, let's do that then, promoting but keeping that on top of unity8's team list
[16:59] <rsalveti> didrocks: yeah, can easily trigger the bug with r54
[16:59] <didrocks> be more relax on the power button-side! :)
[17:00] <rsalveti> yup, sounds fine
[17:00] <didrocks> joke apart, at least, we'll unleash the flood gate for people to push more updates
[17:00] <rsalveti> didrocks: did we fix the lack of video carousel?
[17:00] <didrocks> rsalveti: yeah, this one is supposed to be fixed
[17:01] <didrocks> I think there is no carousel if you have few videos (as I have)
[17:01] <didrocks> but robru tested with more
[17:01] <rsalveti> and the issue that made us unable to start videos from the lens
[17:01] <didrocks> (and this is by design)
[17:01] <rsalveti> let me test :-)
[17:01] <sil2100> didrocks: meeting!
[17:01] <didrocks> rsalveti: please do retest, yeah ;)
[17:01] <didrocks> kenvandine: coming?
[17:02] <kenvandine> didrocks, doh! yeah...
[17:02] <rsalveti> didrocks: no carousel
[17:02] <didrocks> no robru
[17:02] <didrocks> rsalveti: and you do have enough videos to get the carousel?
[17:02] <rsalveti> but can at least launch the video now
[17:02] <rsalveti> didrocks: well, I always had carousel with 4 videos
[17:03] <didrocks> rsalveti: seems it's the official design
[17:03] <didrocks> from what Saviq told
[17:03] <rsalveti> what is the minimum amount of videos needed?
[17:03] <didrocks> I can dig back the bug report
[17:03] <didrocks> one sec
[17:03] <Saviq> didrocks, 6
[17:03] <Saviq> rsalveti, ↑
[17:03] <rsalveti> hm, interesting, let me try that
[17:03] <Saviq> bug #1226288
[17:03] <didrocks> thanks Saviq!
[17:06] <Laney> can we have notify-osd released please?
[17:07] <didrocks> Laney: again a new release?
[17:07] <Laney> hmm?
[17:07] <Laney> is it a problem?
[17:07] <rsalveti> Saviq: yay, working fine :-)
[17:08] <didrocks> Laney: just trying to ask for a reason :)
[17:09] <Laney> Fixes a double g_source_remove() or two
[17:09] <didrocks> Laney: ok, we'll do it
[17:10] <Laney> the autopkgtest fails which blocks migration of some stuff
[17:10] <Laney> actually, let me double check that passes now
[17:11] <didrocks> Laney: robru is doing it now
[17:11] <Laney> ok
[17:15] <robru> Laney, is notify-osd trunk ready for release? or is there an MP i should wait for?
[17:15] <Saviq> rsalveti, cool
[17:16] <popey> hm, i tried to install an app on #55 and it download failed
[17:16] <popey> [unity-scope-click] - DEBUG: click-scope.vala:176: action started: download_failed
[17:17] <Laney> robru: it got merged, but just give me 5 minutes to check it fixes the tests
[17:17] <Laney> would be annoying to have to go around again if not
[17:17] <robru> Laney, ok
[17:17] <popey> 2013-12-09 17:14:09,845 - DEBUG - "Fatal error: /home/phablet/.local/share/ubuntu-download-manager/Downloads/com.ubuntu.developer.doflah.realtai_0.1_all.click failed to install.
[17:18] <popey> Cannot install /home/phablet/.local/share/ubuntu-download-manager/Downloads/com.ubuntu.developer.doflah.realtai_0.1_all.click: Cannot acquire permission to write to /opt/click.ubuntu.com; either run as root with --user, or use "pkcon install-local" instead
[17:19] <popey> drwxr-xr-x 133 dnsmasq ssh 8192 Dec  2 20:57 click.ubuntu.com
[17:19] <popey> wut
[17:22] <Laney> robru: ya, looks good
[17:22] <robru> Laney, ok, on it
[17:22] <Laney> merci
[17:23] <sergiusens> fginther, do you have a minute to discuss the status of android image builders with jenkins?
[17:23] <fginther> sergiusens, sure
[17:25] <sergiusens> fginther, bascially need something like the builder for building ubuntu touch as we had before
[17:26] <sergiusens> fginther, but to build a different branch from the repo to detect breakages
[17:26] <popey> bug 1259253
[17:27] <fginther> sergiusens, what's in the branch?
[17:27] <sergiusens> fginther, a git branch
[17:27] <sergiusens> fginther, well, a bundle of git repos on a different branch; it's for android
[17:28] <sergiusens> fginther, the branch is just a different android version with our patchset on top
[17:29] <fginther> sergiusens, don't we already have some jobs that almost do this? is this just a matter of updating them?
[17:29] <fginther> at least the build part
[17:29] <sergiusens> fginther, yeah, that was my question; we used to have ubuntu-touch-image (the jenkins job); which had a specific assigned builder
[17:30] <sergiusens> fginther, the builders are sort of hardcoded to the job as we don't want to repo sync ~10GB from scratch all the time
[17:31] <fginther> sergiusens, so we did retire some of the machines we were using for these jobs
[17:31] <fginther> sergiusens, but we should be able to identify replacements and get them setup
[17:31] <sergiusens> fginther, sounds good; need a formal request somewhere?
[17:32] <fginther> sergiusens, yes, please: https://bugs.launchpad.net/ubuntu-ci-services-itself/+filebug
[17:32] <fginther> sergiusens, do you have a timeline for when this is needed?
[17:34] <sergiusens> fginther, end of year at the most I think; I'll get back to you on that one (or add it to the bug report
[17:34] <fginther> sergiusens, thanks
[17:34] <sergiusens> thanks to you too :-)
[17:35] <popey> sergiusens: why did the uid for clickpkg change? see second comment on https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1259253
[17:35] <popey> it will break app apps for anyone upgrading to #55
[17:36] <popey> s/apps/upgrades and installs/
[17:39] <robru> sil2100, are you tinkering with url-dispatcher? i just saw it has a yellow prepare job; if you're working on it i'll leave it with you; otherwise i can fix it
[17:40] <sergiusens> popey, the clickpkg user is dynamically created on rootfs build
[17:40] <popey> odd that the users have moved about UIDs
[17:41] <popey> we shouldn't let that happen IMO
[17:41] <sergiusens> popey, I guess that's why android uses hardcoded uids
[17:41] <popey> ☻
[17:41] <popey> any idea which bit of the toolchain I should move that bug to? It's clearly not ubuntu-download-manager at fault
[17:42] <sergiusens> popey, we were supposed to move away from hard coded UIDs but this system image stuff would need us to rethink some stuff
[17:42] <sergiusens> popey, livecd-rootfs would be my guess; but this could probably be fixed with an update hook for the writable parts
[17:43] <sergiusens> cjwatson, any thoughts on clickpkg uid changing across image updates? ^^
[17:43] <cjwatson> system image update hook sounds appropriate
[17:43] <cjwatson> I don't want to give it a fixed uid - it's the wrong trend
[17:44] <cjwatson> adduser --system is the right thing to be using here
[17:44]  * popey fettles the description of that bug
[17:44] <cjwatson> and even if I did give it a fixed uid, it'd still be a different one and we'd need to solve the same problem anyway
[17:44] <sergiusens> agreed
[17:49] <cjwatson> it's clearly not ubuntu-download-manager, indeed.  loath though I am to care about this, maybe click should be shipping a system-image hook, seeing as it owns the clickpkg user
[18:00] <popey> moved it to livecd-rootfs for now. bug 1259253
[18:03] <cjwatson> popey: definitely not
[18:03] <popey> heh
[18:03] <cjwatson> that's several layers above anything that can do anything about it
[18:03] <popey> knock yourself out ☻
[18:04] <cjwatson> I've moved it to click, but won't get to it today
[18:04] <popey> ok, thanks.
[21:15] <rsalveti> bfiller: maybe you know already, but the only crash in 55 is from the dialer app: http://ci.ubuntu.com/smokeng/trusty/touch/mako/55:20131209.1:20131203/5356/dialer-app-autopilot/
[21:15] <rsalveti> cyphermox: robru: are we promoting 55?
[21:16] <cyphermox> rsalveti: I don't know, are we?
[21:16] <rsalveti> seems there are still some missing tests for mako
[21:16] <robru> rsalveti, no idea. i was only working on notify-osd, which is desktop only
[21:16] <cyphermox> which?
[21:16] <robru> today
[21:16] <cyphermox> rsalveti: which? I'm not sure how we'd be involved :)
[21:16] <rsalveti> cyphermox: probably tomorrow only then, didrocks was taking care of it
[21:16] <cyphermox> ok
[21:17] <cyphermox> besides pushing the button, I guess it's up to QA
[21:17] <rsalveti> yeah
[21:17] <cyphermox> didrocks didn't mention any manual testing we should have been doing
[21:17] <rsalveti> he wants to promote 55 (iirc), so maybe some more manual testing (dogfooding) with it should be good
[21:18] <bfiller> rsalveti: need to get boiko to take a look
[21:20] <cyphermox> hrm
[21:20] <cyphermox> rsalveti: didrocks did mention dogfooding
[21:21] <cyphermox> let's split what's missing and we can do the testage.
[21:21] <cyphermox> robru: ^?
[21:41] <popey> rsalveti: i wouldn't promote 55 with bug 1259253
[21:45] <rsalveti> oh, crap
[21:46] <popey> rsalveti: Has it been promoted?
[21:47] <rsalveti> popey: no, but I wanted it to be :-)
[21:47] <popey> heh
[21:49] <plars> popey, rsalveti : pity, the automated tests looked so awesome :)
[21:50] <popey> Well maybe once the mythical mir fix lands we'll get a clean green sheet and we can promote that
[21:50] <popey> #hopeful
[21:51] <robru> cyphermox, yeah I can do some testing. what ya need?
[21:52] <rsalveti> yeah
[21:54] <cyphermox> robru: perhaps nothing after all
[21:54] <cyphermox> so, what do we do with this image?
[22:14] <Laney> how do we get adt-britney to notice that there's a new version of notify-osd which passes its autopkgtest?
[22:18] <cyphermox> Laney: good question. I'd usually ask jibel or pitti about this stuff
[22:22] <Laney> ok, would rather not force - bugs like this happen fairly regularly so would be good to fix
[22:33] <thomi> fginther: if we'd like some CI config changes... is the best thing to file a bug? or talk to someone here directly?
[22:34] <fginther> thomi, lets talk about it first
[22:34] <thomi> fginther: OK, so the first thing is we'd like the full autopilot test suite to be run daily, on amd64 & i386.
[22:35] <thomi> pretty soon we'll have the test suite so it can be run on a phone as well, but we're not there yet
[22:36] <thomi> fginther: I imagine it's already being run *somewhere*, it's just not very visible to us at the moment
[22:36] <fginther> thomi, ack, we can get amd64 and phone added w/o too much trouble
[22:36] <thomi> fginther: maybe leave phone off the list for a while, we're not ready for that
[22:37] <thomi> but we need to know where to go to see the results.
[22:37] <thomi> and I'll make sure the team knows to look at them
[22:37] <fginther> thomi, right, just trying to convey that i386 isn't something we've been doing for autopilot tests
[22:37] <fginther> thomi, so we have no platform configured for that combination
[22:37] <thomi> fginther: I see. I guess maybe it's time to drop i386 support?
[22:37] <thomi> I see
[22:38] <thomi> well, OK, so lets go with amd64 today, amd64 + phone later
[22:38] <fginther> thomi, ok, we'll make i386 a stretch goal
[22:38] <thomi> ok :)
[22:38] <thomi> fginther: the second thing we'd like is for the CI system to block merges that lower the unit test coverage.
[22:39] <thomi> I've already worked out what commands are needed to run the tests and produce the XML coverage report, so I can send that to someone if it makes it easier.
[22:40] <thomi> not sure if it works like this, but if it's easy to make jenkins show the coverage numbers (perhaps a graph) somewhere that would be sweet as well, but if not, as long as we block MPs that regress test coverage we'll be happy :)
[22:40] <fginther> thomi, right. the way we enable coverage for cmake projects isn't going to work here...
[22:40] <thomi> yeah
[22:41] <fginther> thomi, if jenkins is aware of code coverage, it can do a trend graph and it has some facilites for failing on coverage metrics
[22:41] <fginther> will need to review what's easily doable
[22:41] <fginther> thomi, any thing else?
[22:41] <thomi> ok. Can you get back to me on that when you have some time? number 2 is less urgent than number 1.
[22:42] <thomi> fginther: also, while I remember, could you please invite nuclearbob to the subunit  & dashboard meeting? (https://www.google.com/calendar/render?eid=aGd1bDJhNjY3OTZlb3V1bmVoaWhjanAybzRfMjAxMzEyMDlUMjEwMDAwWiB0aG9taS5yaWNoYXJkc0BjYW5vbmljYWwuY29t&sf=true&output=xml)
[22:42] <fginther> thomi, will do on both items
[22:42] <thomi> thanks man, I'll owe you... several :)
[22:42] <fginther> thomi, I'll create a bug in momento
[22:53] <fginther> thomi, can you review https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1259334 and add the details for collecting code coverage?
[22:53] <thomi> fginther: yup, will add the info this afternoon