[01:09] <alecu> any trainguards around to ask about publishing landing-009?
[01:13] <cjwatson> alecu: looking
[01:13] <alecu> thanks
[01:17] <cjwatson> looking at that too :)
[02:05] <imgbot> [03:07] <alecu> Yay
[03:40] <imgbot> [03:40] <imgbot> [07:16] <sil2100> psivaa: I wonder what happened with the UITK tests in the latest image, we seem to have a lot of failures due to an qmlscene crash
[07:17] <sil2100> ogra_: eh, manta and flo are still terrible, we can't even get full test results there still ;/
[07:17] <sil2100> We need to get someone looking at that ASAP
[07:44] <ogra_> sil2100, hmm, and UITK has its hiccup again it seems
[07:45] <sil2100> ogra_: yeah, I poked psivaa about that already
[08:11] <sil2100> brendand: !
[08:11] <sil2100> brendand: so! Could you take a look at two things on the dashboard?
[08:11] <sil2100> brendand: first thing - we seem to have 2 failures each time for system-settings
[08:11] <ogra_> with the new version from 130
[08:12] <sil2100> brendand: and I would concentrate on this one, trying to see if the same tests fail and if they're reproducible
[08:12] <ogra_> it clearly started with the landing
[08:12] <sil2100> brendand: then we would need someone with a keen-AP eye to check if the UITK hiccup in the latest image was an 'accident' as before ;)
[08:13] <ogra_> oh, bot settings failures are related to the dropped phone page ...
[08:13] <ogra_> seems that will just need updating
[08:13] <ogra_> *both
[08:14] <ogra_> (of the tests)
[08:14] <ogra_> sil2100, brendand, seems the UITK failures also have a related unity8 crash
[08:14] <ogra_> (and qmlscene)
[08:14] <psivaa> sil2100: ogra_: i'm rerunning uitk tests
[08:14] <sil2100> unity8? I saw qmlscene
[08:14] <sil2100> Ah, both
[08:15] <ogra_> sil2100, there are two
[08:15] <ogra_> :)
[08:15] <ogra_> i assume unity8 killed the qmlscene instance when crashing
[08:16] <ogra_> sil2100, unity8 itself had a crash during its own tests too
[08:19] <brendand> ogra_, from what i can see the failures are in the About page
[08:20] <ogra_> brendand, but using info from the phoe page
[08:20] <ogra_> *phone
[08:21] <ogra_> hmm, no only one of them
[08:23] <brendand> ogra_, did the mir issue fix land?
[08:23] <ogra_> yep
[08:23] <ogra_> supposedly at least
[08:24] <sil2100> Didn't seem to help flo or manta test-wise though
[08:29] <sil2100> ogra_: can you upgrade your flo/manta and tell us if it's better now?
[08:29] <ogra_> after the meeting, yeah
[08:31] <sil2100> popey: boing
[08:39] <brendand> ogra_, which package do you think broke the imei test?
[08:40] <ogra_> brendand, system-settings changed the way it recieves info from ofono ... (that was what broke the wizard too) ...
[08:40] <ogra_> it moved from ofono-qt to libofono
[08:41] <Laney> what evidence do you have that this is the same?
[08:42] <ogra_> brendand, https://launchpad.net/ubuntu/utopic/+source/ubuntu-system-settings/0.3+14.10.20140711.1-0ubuntu1
[08:42] <ogra_> Laney, well it tries to recieve the imei via dbus but gets an error back ... i think the AP test wasnt updated alongside the switch
[08:43] <ogra_> Laney, it is just a theory :)
[08:58] <sil2100> Holy crap my Firefox crashed when leaving the hangout, it had to be devastated by the meeting ending
[08:59] <Mirv> I can't find an indication of a distro patch to Qt (5.2) regarding the event loop. it was discussed with upstream at https://bugreports.qt-project.org/browse/QTBUG-37677 and downstream marked as Invalid for Qt at bug #1292306 (fixed in Mir)
[09:02] <sil2100> Mirv, ogra_: maybe the workaroudn was in Mir itself?
[09:02] <sil2100> Or in qtubuntu/unity-mir? I remember seeing those branches when there were discussions about that
[09:02] <ogra_> sil2100, it involved Mir ...
[09:03] <Mirv> I remember that Mir devs agreed that upstream is not going to change from what it decided in 5.1.0, so they're adapating to the new model
[09:06] <psivaa> sil2100: uitk is all green. no crash this time
[09:07] <ogra_> i guess it is the same flakiness we saw before
[09:09] <brendand> hmm, now i can't reproduce the system-settings failure
[09:09] <brendand> i'll try a bootstrapped image
[09:12] <sil2100> uh
[09:45] <Laney> it's not reproducible
[09:45] <Laney> by the hand of man
[10:26] <Mirv> popey: spamming complete, and filemanager uploaded
[10:40] <popey> thanks Mirv
[10:41] <popey> Mirv: could you also do dl when you get a mo.. http://s-jenkins.ubuntu-ci:8080/job/dropping-letters-click/lastSuccessfulBuild/artifact/com.ubuntu.dropping-letters_0.1.2.2.57_all.click
[10:48] <ogra_> sil2100, my flo sits on the boot animation since 5 min now ... (wizard ran fine before)
[10:48] <ogra_> ah, finally the UI started
[10:48] <sil2100> Uh
[10:48] <sil2100> 5 minutes?
[10:48] <ogra_> yeah
[10:48] <sil2100> What did it do for so long?
[10:49] <ogra_> no idea ... it has that since a while ...
[10:49] <ogra_> and the UI still hangs hard when starting an app
[10:49] <popey> apport?
[10:50] <sil2100> brendand: any luck with the system-settings thing?
[10:50] <sil2100> Since if not, I guess it's time to kick a new image
[10:50] <sil2100> ogra_: ;/
[10:50] <sil2100> ogra_: so it seems it's still broken for flo then
[10:50] <ogra_> i'd say nothing is fixed here
[10:50] <brendand> sil2100, nope and Laney can't seem to reproduce it either
[10:51] <sil2100> ogra_: could you kick a new image then? We'll at least have the scopes fix
[10:51] <sil2100> om26er: hi!
[10:51] <om26er> sil2100, hey
[10:52] <ogra_> popey, apport on every boot ?
[10:52] <sil2100> om26er: could you help us in checking if the latest images have https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1339700 fixed?
[10:52] <ogra_> unlikely
[10:52] <popey> oh
[10:52] <sil2100> ogra_: we need someone working on this ASAP...
[10:52] <ogra_> i'm just watching the second boot here ... screen timed out the third time now ... with the animation up
[10:52] <sil2100> How can we promote an image if 2 of our officially supported platforms are broken ;/ ?
[10:53] <om26er> sil2100, ok, upgrading to the latest.
[10:54] <om26er> sil2100, which is the latest image currently ? 129 ?
[10:54] <sil2100> om26er: 131
[10:55] <ogra_> so when starting an app it hangs on the start animation too
[10:55] <sil2100> ogra_, brendand: hm, do you think these UI hang-ups in tablets are directly related to the autopilot tests being broken for them?
[10:55] <ogra_> they could
[10:55] <sil2100> ogra_, brendand: since if yes, we can somehow identify more-or-less in which image it started and trying to find the person responsible for it
[10:55] <sil2100> s/person/team
[10:55] <brendand> sil2100, and kill them?
[10:56] <sil2100> NO! Force them to fix it and THEN kill them
[10:56] <ogra_> i guess they are related
[10:57] <ogra_> sil2100, i would guess it started around 123
[10:57] <ogra_> which had a new unity but also a lot of Qt bits updated
[10:58]  * sil2100 chokes Mirv then
[10:58] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/123.changes
[10:59] <ogra_> hmm, not sure the Qt bits are atfault at all ... seems its all just plugins from other changes
[10:59]  * ogra_ falshes 122 ... will take 20-30 min
[11:00] <Mirv> popey: dropping letters done too
[11:00] <Mirv> sil2100: not my Qt stuff. but uitk is there among else
[11:00] <sil2100> :)
[11:01] <ogra_> yeah, UITK and unity8 are the most likely candidates on that list
[11:01] <sil2100> http://people.canonical.com/~lzemczak/landing-team/123.commitlog <- actually, only telephony, UITK and webbrowser stuff from the Qt side
[11:02] <popey> Mirv: ta, will be some more coming
[11:02]  * sil2100 unchokes Mirv 
[11:03] <Mirv> :)
[11:07] <sil2100> ;)
[11:16] <om26er> sil2100, the bug says flo, do I need to test on mako
[11:17] <sil2100> om26er: well, it seemed to have happened also on mako from what I know
[11:17] <sil2100> om26er: and I think it got fixed in mako mostly
[11:17] <ogra_> no, i doubt that
[11:17] <ogra_> but it only shows very rarely there
[11:18] <ogra_> i have like two hangs per day with it ... while flo hangs all the time
[11:24] <ogra_> sil2100, 122 is fine on flo ... installing 123 now
[11:24] <sil2100> ogra_: thanks! :)
[11:34] <popey> sil2100: were you aware that payui 0.2.7 didn't land in the click store because it failed the tests? cc fginther  https://myapps.developer.ubuntu.com/dev/click-apps/878/changerequest/  see http://paste.ubuntu.com/7798095/
[11:34] <sil2100> popey: hm, I was unaware of that
[11:35] <popey> does the payui click get side-loaded in at build?
[11:36] <popey> i cant see it in ogra_ changes
[11:36] <ogra_> http://people.canonical.com/~ubuntu-archive/click_packages/click_list
[11:37] <ogra_> com.canonical.payui_0.2.6_armhf.click
[11:37] <ogra_> obviously still the old one
[11:37] <popey> yes
[11:49] <ogra_> sil2100, so with 123 i definitely have the super slow startup after the wizard ...
[11:50] <ogra_> and confirmed ... starting an app makes the UI hang ...
[11:50] <sil2100> Yeaa!
[11:50] <ogra_> sil2100, so the issue is definitely in the packageset of 123
[11:50] <sil2100> ogra_: btw. could you kick a new image in the meantime?
[11:50] <ogra_> i did
[11:50] <sil2100> ogra_: ok, let's poke the unity8 and UITK people
[11:50] <sil2100> Oh
[11:50] <sil2100> Ok ;)
[11:50] <ogra_> hmm
[11:50]  * sil2100 missed that
[11:50] <ogra_> why did the bot not announce it
[11:51]  * sil2100 slaps imgbot around a bit with a large trout
[11:51] <ogra_> no, rather slap iso.qa.ubuntu.com
[11:52] <ogra_> there is no build running
[11:52]  * sil2100 slaps iso.qa.ubuntu.com around a bit with a large trout
[11:54] <ogra_> stgraber, hmm, i seem to not be able to trigger touch image builds via the qatracker
[11:54]  * ogra_ runs one manually 
[12:00] <imgbot> [12:01] <sil2100> \o/
[12:01] <sil2100> Ok, inbetween stuff, let me check the commitlog agian
[12:02]  * ogra_ makes a bootchart to see what delays the boot so much
[12:02] <sil2100> Saviq: hi! So, we're looking for the root cause of our overall problems with tablet form factors
[12:02] <sil2100> Saviq: this started off with #123
[12:02] <sil2100> Saviq: http://people.canonical.com/~lzemczak/landing-team/123.commitlog
[12:03] <sil2100> Saviq: from what can be seen in the commitlog, the only landings that could have affected that are unity8 and UITK, but I see that the UITK landing seems to be some minor change
[12:03] <sil2100> ogra_: hm, gles update as well, but I guess unrelated
[12:03] <ogra_> Saviq, HAPPY BIRTHDAY !!!
[12:04] <sil2100> Oh!
[12:04] <ogra_> sil2100, well, who knows ...
[12:04] <sil2100> Birthday?
[12:04] <sil2100> Saviq: happy birthday then! :)
[12:04] <ogra_> the mesa update might have impact (it shouldnt, but might)
[12:05] <sil2100> Saviq: yeah, so mesa is also a candidate, but still it would be nice to have someone looking at this
[12:06] <sil2100> ogra_: hmm... actually, maybe you could try downgrading mesa on your 123 image? Do you have some free time?
[12:06] <sil2100> ogra_: since you could download the earlier .deb packages, install them and see if it works (just hope it won't force any removals)
[12:06] <ogra_> i dont even have the free time for what i did up to now ... but yeah, i can try once it is done with the bootchart
[12:07]  * sil2100 is sad the he doesn't have a tablet
[12:07] <ogra_> i doubt mesa has anything to do with it though ... UITK or unity8 is my guess
[12:08] <ogra_> and the unity8 change set is quite big
[12:10] <sil2100> ogra_: UITK doesn't seem to be responsible, it's only a dep-versioning change
[12:10] <sil2100> ogra_: additions of (= ${binary:Version})
[12:12] <sil2100> ogra_: so unity8... but I'm not sure if the symptoms look like unity8-stuff?
[12:12] <Saviq> sil2100, ogra_, thanks!
[12:12] <sil2100> Saviq: ^ could you take a lookie anyways? :)
[12:12] <Saviq> sil2100, that unity8 landing couldn't cause anything
[12:12] <sil2100> Saviq: it seems to affect all tablets
[12:12] <ogra_> sil2100, well, the app-startup animation shows up, the three dots rotate three times and the UI hangs hard for about 30sec
[12:12] <Saviq> sil2100, that unity8 landing just added two (unused atm) properties to the mocks
[12:13] <Saviq> ogra_, sil2100 30s?
[12:13] <ogra_> sil2100, yeah
[12:13] <ogra_> err
[12:13] <ogra_> Saviq,
[12:13] <Saviq> bug #1340086 ?
[12:13] <ogra_> Saviq, got a flo around ?
[12:13] <Saviq> ogra_, mc-tool
[12:13] <Saviq> mc-tool list
[12:13] <ogra_> root@ubuntu-phablet:~# mc-tool list
[12:13] <ogra_> mc-tool list: Failed to connect to D-Bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
[12:13] <ogra_> :P
[12:14] <Saviq> ogra_, sil2100, oh I read the commitlog wrong
[12:14] <ogra_> there is indeed no telephony account on my non-3g flo
[12:14] <Saviq> ogra_, sounds like your phablet session is bad
[12:14] <ogra_> Saviq, well, all sessions since image 123 are
[12:14] <Saviq> sil2100, yes, it's unity8's in-call indicator
[12:14] <ogra_> oh, wait
[12:14] <sil2100> uh oh
[12:15] <Saviq> sil2100, and the above bug in telephony service
[12:15] <ogra_> phablet@ubuntu-phablet:~$ mc-tool list
[12:15] <ogra_> phablet@ubuntu-phablet:~$
[12:15] <ogra_> :P
[12:15] <ogra_> indeed i was root above
[12:15] <ogra_> returns immediately
[12:16] <Saviq> ogra_, correct, but telephony-account times out after 30s, searching for a ofono account
[12:16] <ogra_> Saviq, and that is queried every time i start an app ?
[12:17] <Saviq> ogra_, check ~/.cache/upstart/unity8.log
[12:17] <sil2100> Lunch time, brb
[12:17] <Saviq> ogra_, should have a bunch of https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1340086/comments/2
[12:19] <ogra_> yup, seems i have that ...
[12:28] <ogra_> Saviq, so why would that happen for any app i start then ?
[12:29] <Saviq> ogra_, because we talk to the telephony service when app focus changes
[12:29] <ogra_> dies the startup actually query the telephony accounts when i start an app ?
[12:29] <ogra_> oh, wow
[12:29] <Saviq> ogra_, it's apparently not only on startup
[12:29] <ogra_> right
[12:29] <ogra_> it makes flo completely unusable
[12:29] <Saviq> I can imagine
[12:29] <ogra_> so i assume the slow session startup is related ...
[12:29] <Saviq> yesss
[12:30] <Saviq> let's talk with boiko whether he has a quick fix, otherwise let's revert the in-call hint
[12:30] <ogra_> in the bootchart i see everything starting just fine ... but nothing on screen until about 2 min into the boot ... so i guess it even queries multiple times during startup
[12:32] <ogra_> Saviq, hmm, so i guess the hangs we see on mako are unrelated then ...
[12:34] <Saviq> ogra_, aren't hangs on mako due to Mir deadlock?
[12:35] <sil2100> ogra_, Saviq: the hangs *might* have been fixed now with the last mir upload, so hm
[12:51] <sil2100> For mako that is
[12:53] <ogra_> Saviq, i cant tell
[12:53] <ogra_> right, i dont run -proposed here
[12:57] <sil2100> om26er: were you able to confirm the hang-ups got fixed for mako?
[12:58] <om26er> sil2100, that didn't happen for me
[12:58] <om26er> sil2100, but then I never saw that before as well
[13:01] <ogra_> it is really hard to reproduce since it only happens after a while of usage
[13:04] <sil2100> ogra_: do you remember around what hour boiko appears?
[13:04] <sil2100> I would be nice to have him looking at it ASAP
[13:04] <boiko> sil2100: now maybe? :)
[13:05] <ogra_> not really, but i guess soon :)
[13:05] <sil2100> Oh oooh!
[13:05] <sil2100> ;)
[13:05] <sil2100> boiko: hello!
[13:05] <boiko> sil2100: I'll look into that, but first we need to land the majority of the dual sim work :/
[13:05] <sil2100> boiko: so, it seems there's a serious issue with telephony-service that causes all tablet devices being basically unusable ;/
[13:06] <boiko> sil2100: yep, Saviq reported that to me, I'll look into that soon
[13:06] <sil2100> boiko: https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1340086 <- it would be nice if this could also be a high-priority thing, as per ogra_'s observations it makes tablets really b0rken
[13:06] <sil2100> boiko: thanks :)
[13:16] <rsalveti> sil2100: can I get a silo for line 26?
[13:16] <sil2100> rsalveti: sure, didn't get a ping yet
[13:16] <sil2100> Oh, here it is ;)
[13:17] <rsalveti> :-)
[13:23] <rsalveti> sil2100: thanks
[13:24] <sil2100> yw
[13:25] <sil2100> fginther: ping :)
[13:25] <fginther> sil2100, hey
[13:34] <rsalveti> sil2100: hey, question about the gles packages, I'll create bzr branches for them, and for CI to work properly with them, do we need a project per branch, or would it be fine to use a branch based on the upstream project?
[13:35] <rsalveti> like, having the qtubuntu-gles branch as part of the qtubuntu project
[13:35] <imgbot> [13:35] <imgbot> [13:35] <bzoltan1> sil2100: rsalveti: the UITK build in the silo9 is good to go. It has a two line change in the debian/rules from xnox, so it will need an extra ack
[13:36]  * popey updates
[13:37] <sil2100> bzoltan1: ok, will deal with it in a moment
[13:45] <boiko> sil2100: https://code.launchpad.net/~boiko/telephony-service/fix_freeze/+merge/226828
[13:46] <boiko> sil2100: I'll wait for jenkins to run and then I'll do the checklist and ask tiago to review it
[13:46] <sil2100> boiko: that was FAST
[13:46] <sil2100> WOW
[13:46] <sil2100> ;)
[13:47] <sil2100> boiko: ok, once he approves it, let's please get it in a silo ASAP!
[13:47] <sil2100> boiko: thanks! :)
[13:47] <boiko> sil2100: sure, no problems
[13:47] <sil2100> ogra_: if anything, let's not promote an image before this lands ^
[13:47] <sil2100> ogra_: so I guess no promotions today
[13:53] <sil2100> rsalveti: are you usually publishing silos yourself or can I do it?
[13:53] <sil2100> Ah
[13:53] <sil2100> Ok, I see you publish yourself ;)
[13:53] <rsalveti> sil2100: yeah :-)
[13:53] <sil2100> rsalveti: nvm!
[13:53] <rsalveti> sil2100: not sure if you got my previous question, about the gles packages
[13:54] <sil2100> rsalveti: ah! Sorry, missed it, let me backlog
[13:54] <ogra_> sil2100, indeed
[13:55] <sil2100> rsalveti: so, citrain doesn't require a separate lp project per component, so it can be a sub-branch actually - CI Train only cares if he can merge one branch into another ;)
[13:55] <sil2100> rsalveti: so it's fine
[13:55] <rsalveti> sil2100: lovely, thanks
[13:57] <Saviq> trainguards, can someone please upload the two pkgs from http://people.canonical.com/~msawicz/qt/qtcomp.tar to silo 006 please?
[13:58] <sil2100> Saviq: o/
[13:58] <Saviq> sil2100, please reconfigure the silo, too, added those two as additional source packages
[13:59] <sil2100> Sure thing
[14:05] <brendand_> wow - image notifications are working :)
[14:06] <rsalveti> Saviq: packaging branch might work for some but might confuse some as well (for the gles packages), guess a normal bzr branch will probably be easier
[14:06] <rsalveti> will start from the same root, so they can at least me merged
[14:06] <sil2100> Saviq: packages uploaded
[14:06] <Saviq> sil2100, thanks
[14:07] <sil2100> Had to re-sign them so it took a few moments
[14:07] <Saviq> rsalveti, why confuse? are there source changes ever? and if there are, shouldn't they be patches?
[14:08] <rsalveti> Saviq: no source changes, but I'm thinking about what could happen when someone decides to land something
[14:08] <rsalveti> on a packaging branch you need to point out, or import, the orig tarball
[14:08] <Saviq> rsalveti, so the orig tarball can't be the non-gles one?
[14:09] <rsalveti> Saviq: can, but you'd need to import that when landing something via a silo
[14:09] <rsalveti> and that's when I think it'll confuse some people
[14:09] <Saviq> rsalveti, I think having a separate source branch confuses more :|
[14:10] <Saviq> rsalveti, at least when it's packaging only it's clear it's meant to build from some tarball somewhere, you just need to place it next to the packaging branch
[14:10] <rsalveti> right, but if you want to land both the original and the gles version at the same silo, you'd need to first build the original one and then import the orig tarball in the other
[14:10] <rsalveti> and rebuild the gles version
[14:10] <Saviq> rsalveti, yeah, and why's that bad?
[14:10] <Saviq> rsalveti, that's IMO what should happen anyway
[14:11] <Saviq> rsalveti, at least then it's a clear process of "what to do with -gles packages"
[14:11] <rsalveti> sure, fine by me, hopefully it'll work for everyone :-)
[14:11] <rsalveti> let me give that a shot then
[14:12] <Saviq> rsalveti, if the non-gless builds in the PPA, do you think the train will be able to pick it up from there when preparing the -gles one? or will it require a manual upload anyway?
[14:12] <rsalveti> hm, but you can generate a bunch of orig tarball until you land the branch
[14:12] <rsalveti> and import would mean you need to import in a branch that gets merged
[14:13] <Saviq> rsalveti, and you only really need to update the -gles just before you land
[14:13] <Saviq> rsalveti, I think my ideal workflow would be:
[14:13] <Saviq> 1. build non-gles
[14:13] <Saviq> 2. prepare an MP for packaging-only -gles
[14:13] <Saviq> 3. build -gles
[14:14] <Saviq> 4. -land
[14:14] <Saviq> since before you build non-gles you don't know the version you'll get anyway
[14:14] <rsalveti> right, the 2 step is the one I'm still thinking if it would work
[14:14] <Saviq> and you need to keep those in sync
[14:14] <rsalveti> but should work I guess
[14:14] <rsalveti> bzr bd will probably find the right thing to do
[14:14] <Saviq> that'd be great
[14:15] <rsalveti> we can try and see :-)
[14:15] <rsalveti> let me create the branch for qtubuntu
[14:18] <rsalveti> Saviq: bzr bd merge mode (only the packaging gets included in bzr) needs to find out the orig tarball, it seems there's no support to import the orig tarball in such branch
[14:19] <rsalveti> if we can point that out to look for the orig tarball from the original project, in a ppa, that would work
[14:19] <rsalveti> not sure if doable though
[14:19] <Saviq> rsalveti, not in a PPA probably :|
[14:19] <Saviq> rsalveti, especially when we're looking at multiple PPAs
[14:19] <rsalveti> yeah
[14:20] <rsalveti> "In the future you will be able to use the merge-upstream command to do this for you, but it has not been made to support merge mode yet."
[14:20] <rsalveti> the future that never came
[14:20] <ogra_> but it is bright at least
[14:20] <Saviq> rsalveti, but maybe somewhere where we can upload the tarball after it's generated in the silo...
[14:20] <Saviq> but that starts beating the purpose...
[14:20] <cjwatson> the future's orange
[14:20] <ogra_> :)
[14:20] <cjwatson> git ftw, pristine-tar works much more easily there
[14:21] <rsalveti> yeah
[14:21] <rsalveti> Saviq: then we'd need to keep it in a normal bzr branch
[14:21] <Saviq> rsalveti, no, we can point builddeb to just grab a tarball from somewhere
[14:22] <rsalveti> but then you'd need to upload the package by hand
[14:22] <Saviq> rsalveti, why?
[14:22] <Saviq> rsalveti, I'd need to upload the tarball somewhere
[14:22] <rsalveti> how can you tell it to grab from the ppa?
[14:22] <rsalveti> as you're still landing
[14:22] <rsalveti> right
[14:22] <rsalveti> and put it locally
[14:22] <rsalveti> so it can find it in your machinage
[14:22] <Saviq> rsalveti, as long as we have a place where we put the in-flight tarballs
[14:23] <Saviq> that we want -gles to build from
[14:23] <rsalveti> needs to be a place where bzr bd can find
[14:23] <Saviq> rsalveti, it can be any http server AFAICT
[14:24] <Saviq> rsalveti, as long as it can be parsed into a version thingy
[14:24] <Saviq> rsalveti, stupider idea: since we need -gles MPs per-silo anyway, those MPs could point builddeb to the correct silo...
[14:24] <Saviq> rsalveti, but I agree it's not ideal :|
[14:25] <rsalveti> Saviq: right, not much better than src package uploads
[14:25] <rsalveti> and not sure if that's indeed supported, trying to find out in bzr-bd
[14:26] <ogra_> what happened to "Qt 5.3 will full support runtime detection for GL vs GLES" ?
[14:26] <ogra_> *fully
[14:26] <Saviq> rsalveti, it is, we're using it in qt packaging
[14:26] <rsalveti> qt 5.4 in theory
[14:26] <Saviq> rsalveti, it's dl'ing from qt upstream directly
[14:27] <rsalveti> Saviq: because in our case it'd need to find the orig tarball from a PPA and with a different name
[14:27] <rsalveti> let me grab a qt package branch
[14:28] <rsalveti> ogra_: qt 5.3 only landed that for windows
[14:28] <ogra_> lol
[14:28] <rsalveti> probably because that were the money came from
[14:28] <ogra_> so we should just run out session under wine then
[14:28] <ogra_> *our
[14:30] <Saviq> rsalveti, that's why I was thinking like "Downloads" in https://launchpad.net/qtubuntu for example
[14:31] <Saviq> rsalveti, and yeah, the other stupid idea was to include (the dynamic part of) the URL to the .orig in the MP for -gles
[14:31] <Saviq> but that'd be *so* hacky
[14:33] <rsalveti> Saviq: we can create a custom get-orig-source in debian/rules that can retrieve the tarball from somewhere we want
[14:33] <rsalveti> but then you'd need to change the PPA address to use at every landing
[14:33] <rsalveti> which in theory is fine
[14:34] <cjwatson> Doesn't bzr bd try to use uscan?
[14:34] <cjwatson> So it could go in debian/watch rather than a custom get-orig-source target
[14:34] <cjwatson> Not that that helps much
[14:35] <rsalveti> right, would need to change at every landing
[14:35] <rsalveti> but probably easier to maintain
[14:36] <rsalveti> Saviq: would that work for you?
[14:43] <sil2100> kgunn: so, regarding line 30 - it seems that currently almost all components from that landing (instead of mir) are locked by other silos
[14:44] <Saviq> rsalveti, yeah, that's what I proposed as the "stupider" idea ;)
[14:44] <sil2100> kgunn: how far are you with silo 2 for instance?
[14:44] <kgunn> sil2100: silo2 is on hold for this mir landing actually
[14:44] <kgunn> sorry about that
[14:44] <rsalveti> Saviq: but guess it's the only one if we want a packaging branch
[14:44] <kgunn> we should have said
[14:45] <kgunn> silo 15 is test only
[14:45] <kgunn> silo 6 is test only (atm)
[14:45] <sil2100> kgunn: ok, so let me flush silo 2 in the meantime, no use for it to 'hog' a silo since it will anyway need a rebuild
[14:45] <kgunn> actually....we'll drop silo15 altogether
[14:45] <kgunn> in favor of the unity-mir as part of the mir silo
[14:46] <Saviq> rsalveti, well, the other one I proposed was a static place where we'd upload them, but not overly better
[14:46] <sil2100> kgunn: ok, so 15 can be dropped as well?
[14:46] <rsalveti> Saviq: yup
[14:46] <sil2100> kgunn: so, I'll free up silo 2 and 15 and assign a silo for line 30
[14:46] <sil2100> kgunn: does that sound ok?
[14:47] <sil2100> kgunn: just one last thing - what about silo 16? Will that land soon?
[14:47] <sil2100> kgunn: since 16 has platform-api
[14:47]  * kgunn checks
[14:48] <sil2100> kgunn: it's the QtCompositor landing, importantish it seems
[14:48] <kgunn> sil2100: you mean silo6 not 16 right ?
[14:48] <kgunn> yeah...qtcomp....it will land after mir
[14:48] <sil2100> kgunn: ah! Crap, yes, sorry ;)
[14:49] <kgunn> just a matter of approval churn
[14:49] <sil2100> kgunn: right, 006 I meant, damn
[14:49] <sil2100> Ok, so mir 0.5.0 goes first
[14:49] <kgunn> mir is ready to rock...but qtmir we've got some approvals/reviews to get through
[14:49] <kgunn> yep...thanks
[14:49] <sil2100> kgunn: just a notice though... we'll probably prefer not to land Mir before promoting, and I would expect having a promotion around tomorrow
[14:50] <sil2100> Is that fine?
[14:52] <Saviq> rsalveti, hmm hmm, the custom get-orig-source could try all the 20 silos in theory... but that'd be a problem if the same source would be in two silos...
[14:53] <rsalveti> yeah, no good
[14:53] <rsalveti> we already have one silo that is using qtubuntu for testing (qtmir)
[14:55] <sil2100> kgunn: if that's fine with you then I do those flushes and assign a silo for you
[14:55] <seb128> kgunn, sil2100: just as a fyi, I'm doing a settings landing, which means the qtcompositor silo might need a rebuild later again
[14:55] <sil2100> seb128: ACK
[14:55] <kgunn> seb128: thanks for the heads up
[14:55] <kgunn> sil2100: yes, perfect flush away and prime the pump for mir0.5
[14:56] <kgunn> its a small mir bump
[14:56] <kgunn> basically last little bit needed for trusted prompt sessions
[14:56] <seb128> kgunn, let me know when you are close from landing and that we should stop hijacking your silo btw ... sorry for doing that, but we can't really lock settings work while your test silo is waiting
[14:58] <kgunn> seb128: not a problem!....actually could you or someone you designate please review and approve https://code.launchpad.net/~unity-team/ubuntu-system-settings/use-qtComp/+merge/225540
[14:58] <kgunn> and
[14:58] <kgunn> https://code.launchpad.net/~saviq/ubuntu-system-settings/fix-wizard-sim/+merge/226555
[14:58]  * kgunn check to see they up for review :P
[14:58] <seb128> kgunn, sure, the day it's changed from "work in progress" to "needs review" ;-)
[14:58] <kgunn> seb128: dang it :)
[14:58] <Saviq> kgunn, that last one is landed already
[14:58] <kgunn> ta
[14:59] <kgunn> seb128: ok, changed that one to "needs review"
[14:59] <kgunn> https://code.launchpad.net/~unity-team/ubuntu-system-settings/use-qtComp/+merge/225540
[14:59] <seb128> kgunn, thanks
[15:03] <Saviq> sil2100, can you please reupload qtubuntu-gles to silo 006, but remove TODO from debian/docs first? :|
[15:03] <sil2100> Saviq: hm, let me see
[15:13] <rsalveti> Saviq: mind giving https://code.launchpad.net/~phablet-team/qtubuntu/gles/ a try?
[15:14] <rsalveti> Saviq: you'd need to create an MR bumping the changelog and changing debian/watch
[15:14] <Saviq> rsalveti, I think that'd be awesome enough
[15:15] <Saviq> rsalveti, looks real good
[15:15] <rsalveti> Saviq: great
[15:15] <rsalveti> will do the same for the other ones
[15:16] <Saviq> rsalveti, the only disadvantage I can see is that won't work after the silo is freed
[15:17] <Saviq> rsalveti, but then you'll be able to just pull the tarball from distro instead
[15:17] <rsalveti> yeah
[15:17] <camako> fginther, jenkins is not reviewing my MPs that I put up. Do you happen to know why?
[15:17] <Saviq> rsalveti, so I'm fine with that
[15:17] <Saviq> rsalveti, any preference to where we'd be putting those branches?
[15:17] <sil2100> Saviq: I'll have to bump the version to re-upload...
[15:17] <fginther> camako, do you have an example?
[15:18] <Saviq> sil2100, just the ubuntu part, no?
[15:18] <Saviq> sil2100, that should be fine I think
[15:18] <camako> fginther : https://code.launchpad.net/~cemil-azizoglu/mir/nested_lifecycle_events/+merge/224426
[15:18] <rsalveti> Saviq: under the original projects
[15:18] <sil2100> Yeah
[15:18] <Saviq> rsalveti, lp:qtubuntu/gles?
[15:18] <Saviq> rsalveti, or do we not want to register a series?
[15:19] <camako> someone added "PS Jenkins bot" as reviewer but didn't help
[15:19] <camako> fginther ^
[15:20] <fginther> camako, it should be fixed now, there is an access list that needs to be updated
[15:20] <camako> fginther, thanks
[15:21] <rsalveti> Saviq: a series would be fine
[15:21] <rsalveti> let me create one
[15:21] <rsalveti> for qtubuntu
[15:22] <Saviq> rsalveti, awesomes
[15:22] <rsalveti> Saviq: done, let me do a similar change for the other ones
[15:23] <Saviq> rsalveti, could you make the current ones point at distro and not at a silo yet?
[15:24] <rsalveti> Saviq: sure, just added it initially with a silo/ppa to be easier to change
[15:24] <Saviq> rsalveti, uh oh, just thought or something
[15:24] <ogra_> stop that !
[15:24] <Saviq> rsalveti, if we drive those with MPs, train will overwrite the version
[15:24] <ogra_> :)
[15:25] <rsalveti> Saviq: but on the gles side you'd change the changelog yourself
[15:25] <Saviq> rsalveti, and will try to look for an .orig that doesn't exist
[15:25] <rsalveti> and you'd know already the version you have for the upstream one
[15:25] <Saviq> rsalveti, still, means manual upload to the silo
[15:25] <rsalveti> nops
[15:25] <Saviq> no? ok
[15:26] <rsalveti> Saviq: you bump the changelog for the gles package, let it as UNRELEASED, and it works fine
[15:27] <Saviq> rsalveti, if you say so, we'll find out soon enough :)
[15:27] <rsalveti> :-)
[15:28] <fginther> camako, also, I have a configuration ready to add -ci and -autolanding jobs for lp:mir/0.4 and lp:mir/0.5. https://code.launchpad.net/~fginther/cupstream2distro-config/add-mir-0.4-0.5/+merge/226864
[15:29] <fginther> camako, these are both setup to do the exact same build and testing that is done for the devel branch
[15:31] <ogra_> plars, does the mako 132 testing hang somewhere or am i to impatient again ?
[15:32] <ogra_> oh, ignore me, seems it has actually moved
[15:44] <Saviq> rsalveti, fingers crossed https://ci-train.ubuntu.com/job/landing-006-1-build/110/console
[15:46] <Saviq> rsalveti, so... I forgot to update the ppa, but :|
[15:47] <Saviq> uscan warning: In watchfile /tmp/tmpfcdDzF, reading webpage
[15:47] <Saviq>   http://ppa.launchpad.net/ci-train-ppa-service/landing-021/ubuntu/pool/main/q/qtubuntu/ failed: 404 Not Found
[15:47] <Saviq> uscan could not find the needed tarball.
[15:47] <Saviq> bzr: ERROR: Unable to find the needed upstream tarball for package qtubuntu-gles, version 0.60+14.10.20140715.
[15:47] <Saviq> version gets mangled regardless of my changelog entry
[15:49] <kgunn> ogra_: Saviq ...so when we get to the point where we wanna land qtmir, for the twin do we just need a no-change commit on qtmir/qtmir-gles
[15:49] <kgunn> ?
[15:50] <Saviq> kgunn, we need a separate silo for them, that's for sure
[15:50] <kgunn> add it to the silo and done?...or some other magic needs to happen?
[15:50] <kgunn> right...gets its own silo
[15:50] <Saviq> kgunn, as for no-change commit, the jury's still out on that...
[15:51] <kgunn> cool...i know there's some comments to work through...and slangasek is gonna package review....so we got a day i'm sure
[15:51] <Saviq> kgunn, we're trying to find out whether we can drive it with MPs
[15:51] <Saviq> kgunn, if not, we'll need a manual upload to the PPA
[15:51] <ogra_> right .. -gles packages --> rsalveti
[15:51] <ogra_> :)
[15:51] <sil2100> ;)
[15:51] <kgunn> right...what i refer to as "magic"
[15:52]  * kgunn makes note...magic == rsalveti
[15:52] <ogra_> ++
[15:53] <ogra_> brendand, hmm, didnt you land something for the mediaplayer-app failures ?
[15:54] <ogra_> (scene_selector hasnt been skipped in 132)
[15:55] <sil2100> Maybe elopio did?
[15:55] <sil2100> Since I know he said something about that
[15:56] <ogra_> dunno, i only saw an MP ...
[15:56] <ogra_> i thought that landed actually
[15:56] <fginther> camako, is lp:mir/0.4 now obsolete?
[15:56] <kgunn> fginther: will be
[15:56] <camako> fginther, yes will be soon
[15:56] <kgunn> we're workin' on lp:mir/0.5
[15:56] <elopio> sil2100, ogra_: we have the branches ready.
[15:56] <elopio> not yet landed.
[15:57] <ogra_> ah, k
[15:57] <ogra_> we didnt have the failure in 131
[15:57] <cjwatson> sil2100: Have you thought at all about how we might handle ubuntu-rtm silos in CI Train?
[15:57] <ogra_> thats what made me think it already landed
[15:57] <camako> fginther, @config for lp:mir/0.4, I'd say no need...
[15:57] <fginther> kgunn, camako, thanks, I'll just plan for having 2 job configurations defined and we'll just stagger them as new ones are created and old ones obsoleted.
[15:57] <cjwatson> sil2100: ("no" is perfectly reasonable, just want to check before starting to try to sort through it ...)
[15:58] <camako> fginther... thanks that sounds good too
[15:58] <kgunn> fginther: thanks for letting us be a pain in the butt
[15:58] <sil2100> cjwatson: sadly, no, didn't really get myself up-to-date with that yet
[15:58] <sil2100> Even
[15:59] <cjwatson> OK.  We're going to need to have two sets of silos; the reason to use a derived distro for all this is that it keeps builds insulated from things like chroot updates in the Ubuntu primary archive, and so we'll need one batch of silos for ubuntu and another for ubuntu-rtm
[15:59] <brendand> ogra_, it's in progress still. going to push to get it landed today
[15:59] <cjwatson> Which also means, I think, that people will need to declare in the spreadsheet whether they're targeting RTM or not
[16:00] <ogra_> brendand, yeah, just learned that :)
[16:02] <Saviq> rsalveti, so yeah, no go https://ci-train.ubuntu.com/job/landing-006-1-build/111/console :|
[16:03] <Saviq> rsalveti, train still mangles the date stamp even if you put a changelog bump in
[16:03] <Saviq> rsalveti, so we're back to manual uploads (still the packaging branch is good to have)
[16:03] <Saviq> but it won't be autolanded
[16:05] <sil2100> robru: meeting!
[16:05] <sil2100> brendand: o/
[16:05] <sil2100> and/or elopio o/
[16:07] <elopio> sil2100: I'm having connection problems and keep getting disconnected. I'm sorry.
[16:07] <sil2100> elopio: no problems
[16:08] <elopio> sil2100: the only comment I had for today are the system settings crashes.
[16:09] <ogra_> they seem to be gone
[16:10] <elopio> they are happening a lot on MPs, and yesterday it's the first time I saw them on the dashboard. Seems important.
[16:12] <sil2100> elopio: strange thing...
[16:19] <brendand> sil2100, sorry we had another meeting
[16:19] <brendand> sil2100, filemanager failures - booo
[16:19] <brendand> what's that about
[16:19] <brendand> popey, !
[16:19] <brendand> popey, have you been naughty?
[16:19] <ogra_> it's broken !!!
[16:19] <popey> brendand: !
[16:19] <popey> I have been a good boy and delivered fresh new apps to your phone, yes brendand
[16:19] <rsalveti> Saviq: crap, indeed, it still appends the date
[16:19] <brendand> popey, fresh new broken apps
[16:20] <rsalveti> that's really annoying
[16:20] <popey> brendand: they passed jenkins
[16:20] <popey> fix yo infra bro
[16:20] <ogra_> rsalveti, no way to mangle it ?
[16:21] <Saviq> ogra_, train will always mangle the +foo
[16:21] <rsalveti> yeah
[16:21] <ogra_> ah, evil
[16:21] <rsalveti> not sure if we have an option to skip that
[16:21] <Saviq> ogra_, so well, it'll work as long as you build the same day ;)
[16:21] <Saviq> and the same amount of times
[16:21] <rsalveti> yeah
[16:22] <Saviq> rsalveti, now we need to liaise with sil2100 ;)
[16:22] <Saviq> but I need to go, I'm starting to digest myself from the inside
[16:22] <ogra_> not on your b-day dude !
[16:22] <Saviq> rsalveti, I'm still real happy with what you did, at least it's now something we can follow
[16:22] <ogra_> go have cake !
[16:22] <Saviq> ogra_, yeah, that too ;)
[16:23] <rsalveti> Saviq: oh, happy birthday :-)
[16:23] <Saviq> rsalveti, you already made it! :D
[16:23] <Saviq> thanks o/
[16:25] <sil2100> boiko: silo assigned, spreadsheet should update soon :)
[16:25] <boiko> sil2100: nice, thanks!
[16:27] <asac> sil2100: was there a promotion today?
[16:30] <boiko> sil2100: should I go ahead and build the packages or should I wait until the spreadsheet reflects the silo assignment?
[16:30] <popey> asac: no
[16:32] <asac> k
[16:36] <slangasek> popey, sil2100: hmm, why not?  The known blockers were fixed yesterday, right?
[16:39] <ogra_> slangasek, new blockers
[16:40] <ogra_> slangasek, we only noticed today that the tablets were all completely unusable since a few days ... silo-02 has the fix for that
[16:41] <ogra_> we should be able to promote something tomorrow (after we got enough smoke testing from QA)
[16:41] <ogra_> err ... s/smoke testing/dogfooding/
[16:45] <sil2100> slangasek, asac: no promotions today - we thought that the Mir blocker fix will also make tablets better, but it seemed unrelated
[16:45] <sil2100> slangasek, asac: I won't allow for an image to be promoted that would mean our tablet devices being almost unusable
[16:45] <sil2100> A fix for that is in a silo
[16:45] <sil2100> We'll land that soon and make that our promotion candidate for tomorrow
[16:51] <slangasek> ogra_, sil2100: ok, thanks for the info
[17:17] <xnox> sil2100: hm, why a packaging ack is needed, when packaging change was done by a core-dev?
[17:17] <ogra_> xnox, it isnt
[17:17] <sil2100> xnox: as CI Train doesn't do any smart checking, it just checks if there is a packaging change
[17:18] <sil2100> xnox: if we see a core dev doign the change we auto-publish
[17:18] <cjwatson> human-auto-publish :)
[17:18] <sil2100> i.e. do not check what the change is about
[17:18] <sil2100> cjwatson: right ;p
[17:19] <xnox> =))))
[17:19] <xnox> ok.
[17:34] <sil2100> ogra_: the telephony-service fix released, once it lands in the archive we'll build a new image :)
[17:34] <ogra_> yeah
[17:34] <sil2100> ogra_: I already informed robru about tracking it, but if by any chance you notice it migrating yourself, please feel free to kick an image
[17:35] <ogra_> will  do
[17:35]  * sil2100 goes on to make a long TODO list for tomorrow
[17:35] <sil2100> Things keep piling up
[17:40] <sil2100> o/
[17:51] <bfiller> robru: could you reconfigure silo 10? I added address-book and telephony-service which were not there originally
[18:11] <asac> so tomorrow max care?
[18:16] <ogra_> asac, who is that ?
[18:19] <robru> bfiller, done
[18:20] <ChrisTownsend> trainguards: Hi, could someone hit the publish button for silo-014?
[18:21] <robru> ChrisTownsend, can you mark it testing:pass in the spreadsheet?
[18:22] <ChrisTownsend> robru: Um, sure.  What's the spreasheet link again?  bregma usually takes care of this, but he's out this week.
[18:23] <robru> ChrisTownsend, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc#gid=0
[18:23] <robru> ChrisTownsend, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc#gid=32 rather this page specifically
[18:23] <ChrisTownsend> robru: Thanks, just got the link in the mail too.
[18:24] <ChrisTownsend> robru: So just mark "Testing done" to "Yes", correct?
[18:24] <robru> ChrisTownsend, yes! we have a bot that pings when that's done ;-)
[18:25] <ChrisTownsend> robru: Oh, cool.  Ok.  Nothing like learning by the seat of my pants:)
[18:26] <pmcgowan> ChrisTownsend, welcome to CI madness
[18:26] <ChrisTownsend> pmcgowan: lol, thanks!
[18:36] <ChrisTownsend> robru: Seems a manual ack is needed to publish silo-014.  Is there anything I need to do?
[18:36] <robru> ChrisTownsend, nope, I'm on it
[18:37] <ChrisTownsend> robru: Greats, thanks
[18:37] <ChrisTownsend> Err, great even
[18:37] <robru> ChrisTownsend, you're welcome!
[18:40] <robru> bfiller, the problem in silo 10 is that there's another telephony-service just published from silo 2 which hasn't been merged yet
[18:40] <bfiller> robru: ok, I'll hold off until that merges
[19:06] <robru> bfiller, ah, silo 2 is merged now, your build should work if you want to try it again
[19:09] <bfiller> robru: thanks
[19:09] <robru> bfiller, you're welcome!
[19:22] <rsalveti> robru: new image?
[19:22] <robru> rsalveti, soon. telephony-service is still in proposed according to rmadison
[19:22] <rsalveti> oh =\
[19:23] <robru> rsalveti, shouldn't be long though, LP already says it's landed and the silo even is already merged. so maybe 10mins or so
[19:23] <rsalveti> great
[19:32] <ToyKeeper> Cool, system-settings-wizard crashed after configuring on first boot.
[19:35] <robru> rsalveti, aha, it's landed now, want to kick an image? ;-)
[19:35] <rsalveti> robru: sure
[19:35] <boiko> robru: thanks for triggering the merge&clean job on silo 9
[19:35] <robru> boiko, you're welcome!
[19:40] <imgbot> [19:45] <ogra_> rsalveti, how did you kick that image ? isotracker didnt show that it is re-building
[19:46] <rsalveti> ogra_: nukasan as usual
[19:46] <ogra_> please dont !!
[19:46] <ogra_> we all use the isotracker ... that keeps track if an image is currently building
[19:46] <rsalveti> and how can I use that?
[19:46] <rsalveti> sorry if I lost the memo
[19:46] <ogra_> (and shows that to me if i click on "build" again)
[19:47] <ogra_> http://iso.qa.ubuntu.com/
[19:47] <ogra_> log in ...
[19:47] <rsalveti> when did we change this?
[19:47] <ogra_> about 6-7 months ago
[19:47] <rsalveti> well, we added support for that, I know
[19:47] <rsalveti> but when did we decided not to use nukasan
[19:47] <ogra_> use nusakan if the tracker has issues or so
[19:48] <ogra_> but for general builds better use the tracker so others know you started a build already
[19:48] <ogra_> rsalveti, about 6-7 months ago
[19:48] <ogra_> :P
[19:48] <rsalveti> well, you told me to use nukasan a few weeks ago
[19:48] <rsalveti> :-)
[19:48] <ogra_> when dider was still doing the train
[19:48] <rsalveti> no, that was a while ago
[19:48] <rsalveti> ogra_: anyway, where should I click?
[19:48] <ogra_> rsalveti, i remember ... the tracker was broken
[19:49] <ogra_> no, i mean when dider was still doing the train we changed the rule to use the tracker ...
[19:49] <rsalveti> right
[19:49] <ogra_> so i unchecked all products except touch on the lleft
[19:50] <ogra_> then i click on "utopic daily"
[19:50] <rsalveti> I don't see touch here
[19:50] <ogra_> heh, other way round
[19:50] <ogra_> click utopic daily
[19:50] <rsalveti> right
[19:50] <ogra_> then uncheck all but touch
[19:50] <ogra_> that should leave you with two entries
[19:50] <rsalveti> yup
[19:51] <ogra_> check the checkboxes, scrolll down ... click "update rebuild status"
[19:51] <ogra_> thats it
[19:51] <rsalveti> but then I need to select an arch?
[19:51] <ogra_> the entry next to the checkbox should have (rebuilding) or some such next to it then
[19:51] <ogra_> click the checkbox in the header
[19:52] <ogra_> it selects both
[19:52] <rsalveti> right, but I can only select the checkboxes after I already selected either armhf or i386
[19:53] <ogra_> ?
[19:53] <rsalveti> hm, and I don't see update rebuild status
[19:53] <ogra_> http://iso.qa.ubuntu.com/qatracker/milestones/315/builds
[19:53] <ogra_> thats what i'm looking at
[19:54] <rsalveti> ogra_: that's what I get
[19:54] <rsalveti> but I only see Ubuntu Touch armhf / Ubuntu touch i386
[19:55] <rsalveti> if I click on armhf or i386 I can select all the test cases
[19:56] <ogra_> http://people.canonical.com/~ogra/isotracker.png
[19:56] <rsalveti> but then in the actions I get: Passed with no bugs, subscribe, unsubscribe
[19:56] <rsalveti> ogra_: not what I get here
[19:56]  * ogra_ doesnt get it 
[19:56] <rsalveti> ogra_: not sure if I need to be included in a specific group
[19:56] <ogra_> you need to be in cdimage
[19:57] <ogra_> or alternatively in core-dev i think
[19:57] <rsalveti> thought core-dev would be enough
[19:58] <ogra_> yeah, should
[19:58] <ogra_> but anyway, you would be in both
[19:59] <rsalveti> ogra_: http://people.canonical.com/~rsalveti/iso.png
[19:59] <ogra_> rsalveti, bah
[20:00] <rsalveti> it might need yet another special group :-)
[20:00] <ogra_> looks like a permission issue
[20:00] <ogra_> yeah
[20:00] <rsalveti> ogra_: who can track that down?
[20:01] <ogra_> rsalveti, got it
[20:01] <ogra_> rsalveti, https://launchpad.net/~ubuntu-touch-release
[20:02] <ogra_> cjwatson, can you add rsalveti to https://launchpad.net/~ubuntu-touch-release please ?
[20:02] <rsalveti> oh, an special group :-)
[20:02] <ogra_> that was initially for proposed migration block/unblock
[20:02] <ogra_> but iirc it was also used for the isotracker access
[20:03] <rsalveti> got it
[20:03] <ogra_> so yeah, use nusakan until we got that sorted :P
[20:03] <ogra_> dang
[20:03] <rsalveti> :-)
[20:03] <rsalveti> will use that once I'm allowed :-)
[20:04] <ogra_> thanks
[20:04] <ogra_> we should add sil2100 to it too
[20:07] <robru> ogra_, oh can you add me to the group of people who can kick image builds? seems I'm constantly begging people to do that for me
[20:08] <ogra_> robru, no, i cant, but cjwatson does ...
[20:08] <robru> ah
[20:08] <ogra_> robru, i'll talk to himm tomorrow (he seems gone)
[20:08] <robru> ogra_, thanks
[20:08] <ogra_> and get you, sil and ricardo added
[20:08] <ogra_> (if there are no objections ... i *think* initially team membership was bound to core-devs)
[20:09] <ogra_> (because you can fiddle with proposed migration too with the power this team gives)
[20:09] <robru> ogra_, ah I see.
[20:10] <robru> ogra_, well sil and I are supposed to be working towards core dev status sooner or later...
[20:10] <ogra_> ++
[21:35] <imgbot> [21:35] <imgbot> [21:51] <bfiller> robru: need an reconfigure on silo 10 again please
[21:51] <robru> bfiller, done
[21:51] <bfiller> robru: thanks
[21:51] <robru> bfiller, need the MP url, not branch url
[21:51] <robru> it failed
[21:51] <bfiller> doh
[21:53] <bfiller> robru: fixed
[21:59] <ricmm> robru: hi, silo 009 has been tested and works fine, could you help me publish it?
[21:59] <robru> ricmm, sure one sec
[21:59] <ricmm> thank you
[22:01] <robru> ricmm, you're welcome
[22:03] <ricmm> robru: cheers!
[22:49] <popey> balloons: you about? shall we push fm to the store in readyness for the morning image?
[22:53] <cjwatson> ogra_,rsalveti: done.  I can only add core-devs - that may have been "initially" but hasn't been rescinded.
[22:53] <cjwatson> ogra_: I certainly don't mind Łukasz and Robert being able to trigger image builds, but you'll have to ask stgraber to extend that facility beyond the ubuntu-touch-release team
[22:53] <cjwatson> (maybe we need YA team)
[23:09] <robru> ricmm, false alarm, everything's ok
[23:20] <tedg> robru, Silo please for line 32
[23:21] <robru> tedg, oh oops, I thought I had done it but it failed due to the conflicts in silo 8. ok you got silo 13 now
[23:21] <tedg> robru, Cool, thanks!
[23:22] <robru> tedg, you're welcome!