[05:24] hmm why does my updated mako just flickr and crash unity8... [05:36] (54) [07:07] hey Mirv, how was your week-end? [07:27] hi didrocks, fine (and long!) [07:27] heh, I hope you enjoyed your Friday! [07:27] did you go outside? [07:27] like, were they fireworks and such? [07:30] 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] yeah, I guess so… ;) [07:33] Mirv: did you suffer from issues with latest upstart-app-launch? [07:33] Mirv: there is an ABI transition, so it should have picked other packages as well [07:37] didrocks: so it seems I have some other problem, I just have unity8 flickering and crashing when I try to open it. [07:37] even after I downgraded the upstart-app-launch [07:37] and yes upstart-app-launch has the bump now [07:39] maybe a time for phablet-flash -b to be sure I'm seeing this on image 54 [07:41] Mirv: yeah, sounds like a phablet-flash -b time :) [07:41] can you keep me posted? [07:41] Mirv: FYI, I just reuploaded an url-dispatcher for the soname libupstart change [07:41] Mirv: we don't want the hazardous commit in :) [08:53] ok full flash seems to fix whatever problem I had [08:56] Mirv: ok, good to know - my device is still flashing [08:58] FYI, I've uploaded url-dispatcher from sil2100's branch and disabled automatic rebuilds [08:59] didrocks: thanks! [08:59] didrocks: hm, maybe we should change the driver of content-hub btw.? [08:59] didrocks: since from what I see only Ken has the power to top-approve there right now, which is tragic ;/ [08:59] sil2100: yeah, sounds legit, we will need to ping Ken for it [09:14] 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 === ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: ev | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - [09:22] sil2100: that would be good, but we need Ken to change the driver [09:22] didrocks: why? I see I can do that as well on LP, strangely [09:23] sil2100: oh, if you can, please do then :) [09:25] 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] Mirv: yeah, I guess it is the case [09:26] didrocks: I re-target ted's branch in a moment as well! [09:27] great ;) [09:28] didrocks: can you approve? Would feel silly to do it myself ;p https://code.launchpad.net/~ted/content-hub/ual2/+merge/198210 [09:29] done [09:38] 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] 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] didrocks: FOUND IT! [09:40] https://bugs.launchpad.net/unity-mir/+bug/1234538 [09:40] Ubuntu bug 1234538 in unity8 (Ubuntu) "With Mir enabled - Applications randomly failed to start" [High,Confirmed] [09:40] popey: ok, sounds like the same bug that is getting to be fixed by upstart-app-launch, let's cross fingers :) [09:40] 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] I'm running unity8 + webbrowser, they're quite slow [09:40] bug 1243665 also related [09:40] bug 1243665 in qtubuntu "qmlscene crashed with SIGABRT in QMessageLogger::fatal()" [Critical,Confirmed] https://launchpad.net/bugs/1243665 [09:41] so yeah [09:41] hope so [09:41] all others run so far [09:41] Mirv: ok, then I'll prepare for some click-package testing to make things move faster [09:43] updating landing plan as I go [10:07] Mirv: doing the same, working now on calendar-app [10:14] hmmm, many calendar-app failures, re-running to make sure what's up [10:22] 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] sil2100: I tend to re-run those single failing tests to see if they work alone [10:22] Mirv: could you run calendar-app tests on your device? [10:22] instead of rerunning the whole suite over and over [10:22] sil2100: ok, doing in a moment [10:23] Mirv: yes, but here I get 14 failures, that's like almost all tests [10:32] Mirv: all the other tests look good so far [10:33] Mirv: hm, filemanager also resulted with a lot of tests [10:33] 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] Mirv: do you have the same on your device? [10:34] Re-running the test usually fixes the issue [10:35] Not sure if this can be upstart related? [10:35] didrocks: ^ [10:36] 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] sil2100: really weird, doesn't sounds like upstart, right? [10:40] sil2100: did you try to downgrade? [10:41] didrocks: yes, running the tests with content-hub downgraded, should have results soon [10:41] I mean [10:41] upstart [10:41] .... [10:45] sil2100: I got only 2 failures in calendar-app [10:46] Ok... [10:47] sil2100: and no I haven't seen white screen instead of application kind of thing. now running filemanager. [10:47] I simply ran phablet-config autopilot --dbus-probe enable + phablet-click-test-setup + phablet-test-run now for these click tests [10:47] Mirv: I see it's unrelated, with downgraded upstart I see the same ;/ [10:48] Mirv: I would say, let's release [10:49] 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] Indeed :) Thanks! I wonder what's up with my device, I'll try a reboot and try then [11:05] Mirv: did the tests pass? [11:08] 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] didrocks: 3 failures, same as #54. so publishing now. [11:11] \o/ upstart-app-launch, content-hub and unity-mir + the url-handler that's in daily-release [11:11] I mean [11:11] url-dispatcher [11:11] 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] Damn, so many typos today... [11:16] Mirv: did you check that there is no common files shipped between -1 and -2? [11:17] Mirv: I'm afraid the -dev are shipping the same files without replaces:, right? [11:17] oh, nm, there is the replaces [11:17] Mirv: +1 then [11:18] Mirv: remember that url-handler needs to be uploaded manually [11:18] url-dispathcer* [11:18] ;) [11:21] Mirv: still around? [11:21] sil2100: in case, can you publish them? [11:21] didrocks: sure, what should I do with url-dispatcher though? [11:21] I think we are already really late to get something promoted tonight [11:21] sil2100: I'll upload it [11:22] didrocks: ok, thanks, but sil2100 is apparently doing it now [11:23] content-hub and unity-mir I publish as well [11:24] sil2100: thanks! [11:24] url-dishandler [11:24] 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] sil2100: +1 [11:26] Ok, published, just url-dispatcher left - but I guess didrocks has it covered already [11:26] uploaded [11:38] sil2100: I don't see content-hub [11:41] didrocks: oh, hm, stack is red, wait [11:41] Shit [11:41] sil2100: can we ensure we look at the stacks when publishing them? ;) [11:41] so that we don't end up in situations where things are not published [11:41] (or looking at -changes) [11:41] but but it rarely ever happens that suddenly cu2d reds our a force publish [11:42] bzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/+branch/content-hub/" and relative path "../../../+branch/content-hub/" [11:42] yeah, but better to care rather than being worry [11:42] sil2100: that error is maybe because of the content-hub owner? [11:42] seems like it can't merge back? [11:42] Is it because of my re-targetting branch? [11:42] "The lp-propose command returned an error." [11:42] probably yeah [11:42] Will a redeploy of the stack help? [11:43] sil2100: depends, does the bot and you have access right to the redeploy one? [11:43] retargeted* [11:43] The retargetted one is in ~phablet-team, so it should be fine [11:43] ok, so redeploy [11:43] with -U [11:43] not -US [11:46] 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] sil2100: yep [11:51] didrocks: ok, this time it went through [11:51] didrocks: noting down to make sure stacks get published when publishing [11:55] sil2100: thanks! [12:06] 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. === MacSlow is now known as MacSlow|lunch [12:14] cjwatson: retriggered... after ~15 reloads (LP timeouts on recipe pages are really bad) [12:14] https://code.launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+recipebuild/603481 [12:15] thanks, let's see [12:18] Mirv: oh! You haunted by this as well? [12:19] cjwatson: looks good now! [12:19] sil2100: dejavu... :D [12:20] Mirv: excellent [12:21] so just stupid handling of forced removals of packages in the chroot, not failed :any support at all [12:22] 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] sil2100: I'd guess your similar issue might be resolved now too [12:27] Mirv: yay, although it's no longer an issue, the guys found a workaround for that [12:30] cjwatson: hum, I'm not really sure to understand something in the build-dep wait [12:30] https://launchpad.net/ubuntu/+source/url-dispatcher/0.1+14.04.20131209.1-0ubuntu1/+build/5317569 [12:31] -> but rmadison libupstart-app-launch2-dev [12:31] says it's published in -proposed [12:31] I'm sure I'm missing an obvious typo mistake… [12:31] it's in universe [12:31] oh right [12:31] url-dispatcher source is in main and can only use binaries in main [12:31] * didrocks promotes [12:31] yeah yeah [12:31] sorry for the ping [12:31] I'll move it [12:32] thanks cjwatson :) [12:32] it should auto-retry (eventually) [12:33] oh dear, why the new build-dep on liblttng-ust-dev? [12:33] I guess it's a question for tedg once he's around [12:34] that'll need to be made architecture-specific - see "apt-cache showsrc ust | grep ^Architecture" === Ursinha-afk is now known as Ursinha [12:34] (please don't make it [!arm64] - make it a subset of the positive architectures supported by ust instead) [12:35] oh, so we'll have url-dispatcher blocked in proposed I guess? [12:36] as it will be in dep-wait [12:37] yes [12:39] cjwatson: why not this !arm64 btw? [12:39] but rather listing explicitely [12:39] Two reasons [12:39] 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] Secondly, we'll have another new port shortly which is also not in ust's list [12:40] cjwatson: ok, I'll use the same list than for ust (including debian ones then) [12:40] thanks cjwatson [12:40] It should also make it easier to visually spot discrepancies in future [12:40] (you could put a comment above it in the control file, e.g.) [12:40] (already there ;)) [12:40] heh, ok [12:43] (uploaded) [12:50] cjwatson: in fact, it's upstart-app-launch which deps on ust [12:51] cjwatson: so, I just uploaded that one (in addition, to url-dispatcher) [12:51] ok [12:51] 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] but should I keep them as arch: any and we remove the binaries on other archs to help britney? [12:51] or should I list the arch for all of them? [13:00] cjwatson: ok, I guess I'm going to list then [13:01] didrocks: I don't understand. Why would we remove them? [13:01] Confused. [13:02] 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] I guess as the list is written in debian/control, britney will let go it through [13:02] No [13:02] ah? [13:02] Why can't upstart-app-launch continue to build on arm64, just without ust? [13:03] ok, for that, we'll need upstream support I guess then === alan_g is now known as alan_g|lunch [13:03] which is then going to block an image promotion [13:03] I understood you wanted Architecture: [13:03] No, I was expecting Build-Depends: liblttng-ust-dev [list] [13:04] But it's a question. Is this truly mandatory now or can it have a sensible fallback? [13:04] cjwatson: let me look at the code [13:04] The new ust in the archive seems to cause some trouble for us? Or the troublesome part is the upstart dependency here? [13:04] upstart-app-launch, not upstart [13:04] Nothing to do with the new ust either [13:04] Please read the scrollback [13:05] Right, by upstart I mean upstart-app-launch, just was saving up typing time [13:05] Please don't do that :P [13:05] Ok, so the new dep then ;) [13:05] didrocks: if it's truly mandatory, adding an explicit architecture list achieves nothing and we should remove the binaries [13:06] didrocks: And indeed the changes you uploaded were largely pointless, I'm afraid [13:06] cjwatson: it sems to me [13:07] didrocks: If you'd given me an opportunity to review the diffs :P [13:07] cjwatson: it seems to be mandatory [13:07] Then it might as well just dep-wait [13:07] cjwatson: well, sorry, I was assuming that britney parsed debian/control to take decisions [13:07] An explicit architecture list is just something that needs to be kept in sync in future [13:07] No, it doesn't, and this is well-documented [13:07] https://wiki.ubuntu.com/ProposedMigration gives the full list of criteria [13:08] cjwatson: yeah, I read the page but didn't read back [13:08] I'd actually recommend reverting those changes again if liblttng-ust-dev is mandatory [13:08] 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] cjwatson: agreed, but i'll just prepare that in trunk [13:08] without re-releasing [13:08] if you don't mind [13:08] sure [13:08] ok, so, I guess once upstart-app-launch is built, what is needed is: [13:09] * promote the new binaries to main [13:09] (if not done already) [13:09] * removing the arm64 and powerpc? [13:09] what has powerpc got to do with anything, aside from your vendetta against it? :P [13:09] * doing that removal for all deps of libupstart-app-launch* [13:09] ust builds on powerpc [13:10] cjwatson: sorry, it was too much at the end of the list for my brain to catch it :) [13:10] so yeah, arm64 only [13:11] I'm looking through its rdeps [13:12] cjwatson: content-hub, url-dispatcher and unity-mir IIRC [13:12] ugh, painful [13:12] I'm not going to rely on memory ... [13:12] there are indicators and such too [13:12] for ust itself, right [13:12] I wish upstream had discussed this with foundations first [13:13] yeah, going to be painful :/ [13:13] removing architectures is an annoying thing to do [13:13] agreed [13:15] cjwatson: can I help for anything? [13:18] don't think so, I'm just chasing the dep chain [13:18] ok, revert done in trunks FYI for the arch: list thing [13:22] 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] didrocks: so if I remove it it'll just reappear on the next upload [13:23] cjwatson: ok, so for this one, I need to change the binary dep to list archs [13:23] 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] cjwatson: with a comment, I think that could do it, I'll get you something to review [13:24] didrocks: or maybe on a less intrusive binary package [13:24] didrocks: libupstart-app-launch2-dev? shame there's no unversioned -dev package there [13:24] didrocks: upstart-app-launch itself is quite heavyweight for a b-d, it depends on click/click-apparmor [13:25] cjwatson: yeah, I already had that discussion with tedg, hard to get them agreeing on what we need for a -dev [13:25] cjwatson: ok, doing on libupstart-app-launch2-dev [13:25] ok, thanks [13:25] I've removed url-dispatcher and its rdeps [13:25] thanks :) [13:25] so I think just upstart-app-launch and unity-greeter-session-broadcast are left [13:26] upstart-app-launch has just been published I guess [13:26] (seeing it in rmadison) [13:26] I wasn't waiting for that anyway [13:26] since I'm removing things from trusty, it doesn't matter [13:26] indeed [13:27] hopefully systemtap/ust will get ported to arm64 soon - I see there's upstream work in progress on it [13:27] ah, excellent, so the consideration to dep on ust will be valid or better to still chat with ted? [13:27] it's still a roadblock to new ports; I still think it should be optional [13:28] it's a heavyweight and complex piece [13:28] which is hard to port [13:28] cjwatson: ok, I'm noting to talk to ted then [13:28] thanks [13:30] cjwatson: how about that description? https://code.launchpad.net/~didrocks/unity-greeter-session-broadcast/add-upstart-app-launch-build-dep/+merge/198259 === josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - === alan_g|lunch is now known as alan_g [14:00] 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] 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) === MacSlow|lunch is now known as MacSlow [14:28] didrocks: r=me (for whatever that's worth) [14:28] didrocks: I haven't done the removal, am waiting for unity-greeter-session-broadcast to land [14:29] cjwatson: you mean, in trunk or in archive? is that blocking? (we have an image build depending on it) [14:29] 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] just want to get an image build and promoted [14:31] didrocks: trunk would be fine [14:31] cjwatson: ok, I top-approved === gatox_ultra is now known as gatox [14:48] 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] ah merged :) [14:52] cjwatson: ok, so upstart-app-launch binaries and unity-greeter-session-broadcast are the last ones I guess ^ [14:52] (should be all good now) [14:55] \o/ [14:57] didrocks: removed [14:58] 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] it's on iso.qa, not on cdimage [15:03] cjwatson: I'll try to sync up with stgraber asap to know where this tool is [15:03] didrocks: http://iso.qa.ubuntu.com, log in [15:03] (done) [15:03] should be usual sso [15:04] I don't see anything [15:04] You are currently on: Ubuntu ISO Testing [15:04] and then, nothing [15:04] then select "Trusty Daily" on the front page [15:04] check "Ubuntu Touch armhf", scroll to the bottom, check that it says "Request a rebuild" under "Rebuilds", press "Update rebuild status" [15:05] in the actions, I only have "passed with no bugs", "subscribe", "unsuscribe" [15:05] I logged in checking the touch release team [15:05] let me logout and retry [15:06] cjwatson: confirming I don't see any Rebuilds section on http://iso.qa.ubuntu.com/qatracker/milestones/308/builds/58757/testcases [15:08] try http://iso.qa.ubuntu.com/qatracker/milestones/308/builds [15:08] you shouldn't actually *click* on Ubuntu Touch armhf [15:08] just check the checkbox beside it [15:08] cjwatson: ah ok, yeah, you're right, was just one path to deep [15:08] sorry for being so dummy… === greyback is now known as greyback|london === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [16:17] didrocks: how are we in terms of merging/landing new stuff in the archive? [16:17] 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] rsalveti: we are in hell :) [16:18] rsalveti: yeah, I just kicked an image build, for the promotion candidate [16:18] rsalveti: I would prefer before we promote it we don't take risks please [16:18] we had enough collisions… :/ [16:19] ok, will get the code in trunk and available in a ppa for now, will ping you again tomorrow then [16:21] rsalveti: let's really cross fingers we can promote this time… [16:21] seems it's really easy to reproduce bug 1258655 with latest image [16:21] bug 1258655 in Unity 8 "Abort when blanking/unblanking screen" [High,Triaged] https://launchpad.net/bugs/1258655 [16:22] not sure if we want to fix that first before promoting a new image [16:22] it's kind of a blocker for dogfooding imho [16:22] I could get unity8 to crash a bunch of times in a row [16:25] rsalveti: last comment from Saviq told it's not a regression compared to latest promoted image [16:25] didrocks: right, but it seems way easier to reproduce it now [16:25] I was using the phone for a few minutes and could make it crash a few times already [16:25] the issue was probably there already [16:26] yeah, just easier to trigger hum… [16:26] but something changed with latest unity8 that made it easier to be triggered [16:26] 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] rsalveti: however, putting that one on top of Saviq's team list [16:26] does it sound ok for you? [16:57] didrocks: yeah, can easily trigger that [16:58] rsalveti: ok, let's do that then, promoting but keeping that on top of unity8's team list [16:59] didrocks: yeah, can easily trigger the bug with r54 [16:59] be more relax on the power button-side! :) [17:00] yup, sounds fine [17:00] joke apart, at least, we'll unleash the flood gate for people to push more updates [17:00] didrocks: did we fix the lack of video carousel? [17:00] rsalveti: yeah, this one is supposed to be fixed [17:01] I think there is no carousel if you have few videos (as I have) [17:01] but robru tested with more [17:01] and the issue that made us unable to start videos from the lens [17:01] (and this is by design) [17:01] let me test :-) [17:01] didrocks: meeting! [17:01] rsalveti: please do retest, yeah ;) [17:01] kenvandine: coming? [17:02] didrocks, doh! yeah... [17:02] didrocks: no carousel [17:02] no robru [17:02] rsalveti: and you do have enough videos to get the carousel? [17:02] but can at least launch the video now [17:02] didrocks: well, I always had carousel with 4 videos [17:03] rsalveti: seems it's the official design [17:03] from what Saviq told [17:03] what is the minimum amount of videos needed? [17:03] I can dig back the bug report [17:03] one sec [17:03] didrocks, 6 [17:03] rsalveti, ↑ [17:03] hm, interesting, let me try that [17:03] bug #1226288 [17:03] bug 1226288 in Unity 8 "Carousel should only be used when there's enough items" [Medium,Fix released] https://launchpad.net/bugs/1226288 [17:03] thanks Saviq! [17:06] can we have notify-osd released please? [17:07] Laney: again a new release? [17:07] hmm? [17:07] is it a problem? [17:07] Saviq: yay, working fine :-) [17:08] Laney: just trying to ask for a reason :) [17:09] Fixes a double g_source_remove() or two [17:09] Laney: ok, we'll do it [17:10] the autopkgtest fails which blocks migration of some stuff [17:10] actually, let me double check that passes now [17:11] Laney: robru is doing it now [17:11] ok [17:15] Laney, is notify-osd trunk ready for release? or is there an MP i should wait for? [17:15] rsalveti, cool [17:16] hm, i tried to install an app on #55 and it download failed [17:16] [unity-scope-click] - DEBUG: click-scope.vala:176: action started: download_failed [17:17] robru: it got merged, but just give me 5 minutes to check it fixes the tests [17:17] would be annoying to have to go around again if not [17:17] Laney, ok [17:17] 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] 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] drwxr-xr-x 133 dnsmasq ssh 8192 Dec 2 20:57 click.ubuntu.com [17:19] wut === gatox is now known as gatox_lunch [17:22] robru: ya, looks good [17:22] Laney, ok, on it [17:22] merci [17:23] fginther, do you have a minute to discuss the status of android image builders with jenkins? [17:23] sergiusens, sure [17:25] fginther, bascially need something like the builder for building ubuntu touch as we had before [17:26] fginther, but to build a different branch from the repo to detect breakages [17:26] bug 1259253 [17:26] bug 1259253 in ubuntu-download-manager (Ubuntu) "Application fails to install after downloading #55 mako" [Undecided,New] https://launchpad.net/bugs/1259253 [17:27] sergiusens, what's in the branch? [17:27] fginther, a git branch [17:27] fginther, well, a bundle of git repos on a different branch; it's for android [17:28] fginther, the branch is just a different android version with our patchset on top [17:29] sergiusens, don't we already have some jobs that almost do this? is this just a matter of updating them? [17:29]