[02:05] <imgbot> [03:05] <imgbot> [03:30] <imgbot> [03:30] <imgbot> [03:40] <tedg> trainguards, Can I get a silo for line 51?
[03:41] <robru> tedg: ha! you just caught me on the way out for dinner. silo 11.
[03:43] <tedg> robru, Awesome, thanks! :-)
[03:45] <robru> tedg: you're welcome
[04:20] <imgbot> [04:20] <imgbot> [04:23] <ToyKeeper> Hmm, that answers that question.
[05:41] <Mirv> morning
[05:47] <Mirv> hmm, wtf happened to my qtdeclarative line on spreadsheet, and how does it seem bzoltan's line 40 has kind of assimilated it
[05:49] <Mirv> bzoltan_: could you look at line 40 and and least make it like you'd like it to be? the MP is about phablet-tools, yet the bug is about qtdeclarative and it has qtdeclarative as manually uploaded package
[05:49] <bzoltan_> Mirv:  geez... not again a CI sheet conflict
[05:51] <Mirv> bzoltan_: I haven't seen that, but is it something like not everything is shown to everyone, then they add a line, and they somehow get mixed up?
[05:51] <Mirv> I can see sil2100 "reconfigured" my silo adding phablet-tools to it.. https://ci-train.ubuntu.com/job/prepare-silo/4142/console
[05:51] <Mirv> but the bug link isn't from my line even
[05:51] <Mirv> yes it's qtdeclarative but not the bug my landing in silo 012 was supposed to be about :S
[05:52] <bzoltan_> Mirv:  I do not know. I deleted the crap
[05:52] <bzoltan_> Mirv:  I have not added those junk text there :)
[05:53] <Mirv> bzoltan_: this make me very trusting that the rest of the spreadsheet has not gone completely mixed :)
[05:54] <Mirv> bzoltan_: ok, you've your silo now reconfigured to have your actual landing, and I readded my own line
[05:55] <robru> Mirv: bzoltan_ I've been seeing a lot of mixups like this lately, whenever it happens to you, please reload the sheet. Sometimes it goes away.
[05:56] <Mirv> robru: it can't go away if a silo has already been reconfigured to have two landings mixed :)
[05:56] <robru> Mirv: true
[05:56] <Mirv> go Google!
[05:57] <robru> Mirv: yeah i dunno how this is getting worse, replacing the spreadsheet is top priority
[06:52] <oSoMoN> ogra_, hey, if/when you’re around, I need a packaging ack for https://ci-train.ubuntu.com/job/ubuntu-landing-025-2-publish/17/artifact/packaging_changes_webbrowser-app_0.23+15.04.20150217.1-0ubuntu1.diff
[06:54] <oSoMoN> trainguards: good morning! I need a binary copy of oxide-qt 1.5.3-0ubuntu1 from https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/+packages to silo 3
[06:55] <robru> Mirv: can you grab that? I'm afk
[06:58] <Mirv> robru: sure
[06:58] <Mirv> oSoMoN: sure
[06:58]  * Mirv is very sure
[06:58] <robru> Mirv: thanks ;-)
[06:58] <Mirv> oSoMoN: I tried also on #ubuntu-devel but maybe we need ogra if no-one else volunteers
[07:01] <Mirv> oSoMoN: we got it from mitya57
[07:04] <oSoMoN> Mirv, thanks!
[07:04] <Mirv> now all I'd need is an archive admin to approve compiz-mate binary package addition, no luck yesterday or today so far
[07:17] <bzoltan_> Mirv:  was the rtm image 237 ditched or what?
[07:29] <robru> Mirv: Hmmmmmmm silo 3 diff is empty, that's suspect.
[07:31] <Mirv> bzoltan_: I'm not sure, you mean in terms of verification? I think signoffing and landing is still ongoing today.
[07:31] <Mirv> robru: maybe because it needs to diff around 2.5GB against another 2.5GB, something runs out?
[07:32] <Mirv> robru: luckily not disk space though :)
[07:33] <robru> Mirv: I should hope that debdiff tool doesn't explode just because the filesize
[07:33] <Mirv> robru: no, it's not that, I've debdiffed oxide locally just fine
[07:33] <robru> Mirv: I'm poking at it now...
[07:35] <robru> Mirv: oh I see... one sec
[07:38]  * ToyKeeper wonders when bfiller gets up...  probably not for several more hours
[07:39] <robru> ToyKeeper: gets up? hah! he probably just went to bed recently. it's not even midnight us west coast
[07:39] <ToyKeeper> Probably need to confirm if a silo can land even though the bugfix has an unfortunate side effect.
[07:39] <ToyKeeper> (in rtm-017, one of the bug fixes eliminates an accidental feature which allowed it to produce higher-quality photos)
[07:41] <robru> Mirv: oh btw, what I told you before about needing FORCE_REBUILD and WATCH_ONLY to regenerate diffs is no longer true. WATCH_ONLY now regenerates diffs by itself, that seemed more sensible to me.
[07:44] <Mirv> robru: right, that's great!
[07:44] <Mirv> ToyKeeper: the usual default is indeed that flash is used for focusing if when flash itself is turned off
[07:45] <ToyKeeper> Mirv: But it no longer uses the flash for focusing after applying this bugfix.
[07:46] <Mirv> ToyKeeper: yes, I just mean that indeed that's wrong, the default should be flash used for focusing even if there wouldn't be a setting for controlling it
[07:47] <Mirv> or well, I have seen also phones that do this same thing.
[07:47] <ToyKeeper> Ah, okay.  So it sounds like this is less a grey matter and more of a fail.
[07:47] <Mirv> yes it's a rather grey matter. some people prefer that they can actually make the phone not to use the flash (for example it's banned to use flash in museums)
[07:48] <ToyKeeper> Oh, it definitely is better to have the option rather than letting the phone be too smart for its own good.  :)
[07:49] <ToyKeeper> But I feel that way about pretty much any attempt at software being clever.
[07:56] <bzoltan_> Mirv:  I mean that the RTM #237 is not listed here -> http://people.canonical.com/~ogra/touch-image-stats/rtm/ But it was the latest proposed when I validated the UITK landing... and it brought a broken gallery what made my testing invalid. Not nice ...
[08:01] <robru> Mirv: hah: https://ci-train.ubuntu.com/job/ubuntu-landing-003-1-build/lastSuccessfulBuild/artifact/full_oxide-qt.diff/*view*/ 366MB diff, got it working at least.
[08:08] <Mirv> robru: now we just need to review it properly!
[08:08] <Mirv> but yes, working = good
[08:08] <robru> Mirv: good luck ;-)
[08:09] <Mirv> bzoltan_: that's probably just ogra's scripts not running or something, as it's missing 237+238
[08:09] <ogra_> well, there were most likely device tarball or custom tarball changes ... if there are no rootfs changes -> no changelog
[08:10] <Mirv> oh right, there were those
[08:10] <seb128> is anyone looking at u1 accounts being lost on rtm > 234 updates?
[08:10] <ogra_> seb128, it is most likely due to the server wanting to refresh the token ...
[08:11] <ogra_> your token gets invalid on the phone when that happens
[08:11] <ogra_> we need better user feedback for this
[08:11] <seb128> why is that happening only after an update?
[08:12] <seb128> ogra_, dbarth is saying something else on -touch
[08:12] <ogra_> dunno ... before the old account stayed around and people were wondering why app updates stopped workin
 seb128: apparently because the apparmor extension is missing, and the u1 lib now expects it to be there
[08:12] <ogra_> how could that lib land without this in place ?
[08:13] <ogra_> this needs to be a dependency then
[08:14] <seb128> https://bugs.launchpad.net/ubuntu/+source/signon/+bug/1392380/comments/17
[08:14] <seb128> so yeah
[08:14] <seb128> bug, not token from server issue
[08:15] <bzoltan_> ogra_: Mirv:  anyhow, there must be a gallery app change between 236-237 what introduced failing tests
[08:16] <ogra_> seb128, well, 239 has the fix then
[08:17] <seb128> my u1 account is not back though
[08:18] <seb128> dbarth, ^ do we need to add the account again anyway?
[08:20] <bzoltan_> ogra_: Mirv: can you guys confirm this gallery change?
[08:21] <ogra_> bzoltan_, i can confirm that no rootfs changes happened :)
[08:21] <ogra_> nothing else
[08:21] <Mirv> bzoltan_: ogra_: no, gallery is 2.9.1.1136 from end of January
[08:22] <bzoltan_> ogra_:  so you say that the 236 and 237 are identical? Because I did capture a gallery test regressions.
[08:22] <ogra_> no, i say that the rootfs hasnt changed
[08:22] <ogra_> iirc 237 had some fixed for factory mode or so ...
[08:23] <ogra_> *fixes
[08:23] <ogra_> in the device tarball
[08:23] <ogra_> and 238 was a new custom tarball ... no idea what changed there
[08:24] <bzoltan_> Mirv: Ok, the gallery did not change. What about the gallery tests?
[08:24] <Mirv> bzoltan_: the RTM branch of gallery is untouched
[08:25] <Mirv> bzoltan_: but, maybe the phablet-click-test-setup checks out trunk instead?
[08:25] <bzoltan_> Mirv:  something caused the gallery test failures from 236 to 237
[08:25] <Mirv> bzoltan_: oSoMoN fixed gallery-app test failures in _trunk_ 19 hours ago https://code.launchpad.net/~phablet-team/gallery-app/trunk
[08:25] <Mirv> if phablet-click-test-setup checks out trunk AP:s instead of rtm AP:s, that would explain it
[08:26] <bzoltan_> Mirv:  Yeps... that was it. 19 hours ... that is exactly between my reference  and silo testing
[08:26] <Mirv> bzoltan_: so it's not tests failing, it's wrong tests
[08:27] <Mirv> bzoltan_: but nothing in rootfs really changed in 237 and 238
[08:27] <bzoltan_> Mirv:  Clear.
[08:41] <bzoltan_> brendand: jibel: Guys, I have marked the silo1 tested and pasted the test results to the usual cell in the sheet. The silo validation for UITK takes ages, like 12-14 hours a round. You do not need to run the test plan. All the tests are done. If you have questions please ping me _and_ kalikiana. I hope that this UITK fix can make it to the the w9 freeze.
[08:43] <Mirv> bzoltan_: we'll have a hangout in 45mins, after that we'll know more
[08:44] <bzoltan_> Mirv:  Cool :) please push the UITK :)
[08:45] <jibel> bzoltan_, that'll be short for this milestone. There are still huge updates in the queue, like calendar and camera
[08:45] <jibel> bzoltan_, but we'll do our best
[08:49] <bzoltan_> jibel: it is up to you guys. The cursors issue this UITK fixes seemed to be rather important
[08:49] <seb128> dbarth, so, should I add back my u1 account manually, or keep it in that state in case somebody wants to fix it and need a system to verify the fix on?
[08:56] <brendand> Mirv, any idea why QLibrary.load() would fail?
[08:58] <brendand> Mirv, the error looks like this - http://pastebin.ubuntu.com/10287481/
[09:00] <Mirv> brendand: at least out of context that doesn't tell me anything.. it'd sound like it doesn't find a library or something?
[09:01] <brendand> Mirv, yeah. i'm not really sure where it looks
[09:02] <brendand> Mirv, the location is on both QT_PLUGIN_PATH and LD_LIBRARY_PATH
[09:15] <dbarth> seb128: you can add it back, we have a way to reproduce in a bug report
[09:15] <seb128> dbarth, thanks
[09:15] <dbarth> seb128: mardy is looking into this right now
[09:15] <seb128> great
[09:52] <popey> sil2100: jibel if we add calendar to dashboard, won't that need calendar to already be in the image?
[09:52] <sil2100> seb128: hey! Do you know if there's any progress made on the failing ubuntu-system-settings AP tests?
[09:52] <davmor2> popey: it will be in the next image unless things go very wrong
[09:53] <jibel> popey, it should be on next image
[09:53] <popey> ok
[09:53] <sil2100> popey: as they mentioned, it should be in the next image so we should be safe to add it now
[09:53] <popey> ok
[09:53] <jibel> and if it is not and it fails, we'll know why :)
[09:53] <popey> hah
[09:53] <seb128> sil2100, no, we have no clue what's the issue, we can't reproduce on devices and the issue on the ci run seems in qtfeedback
[09:53] <sil2100> seb128: the changes that are causing almost all tests to fail also landed on ubuntu-rtm yesterday and we would need those fixed before we can get an image promoted
[09:53] <seb128> that's what I understood from what Ken said the other day
[09:53] <sil2100> oh
[09:54] <popey> cihelp Hello! Can we please get calendar app autopilot tests added to the dashboards? (it was removed a while ago, but we're adding it back to the image)
[10:08] <bzoltan_> sil2100: jibel: I saw that we have time until 2pm UTC. Who to bribe to pull the UITK up in prioroty? It has a fix what effect _ALL_ text input in _ALL_ apps.
[10:08] <sil2100> bzoltan_: no worries, QA will sign-off your silo after silo 11 and calendar
[10:09] <bzoltan_> sil2100:  Okey...now all I need is an IBAN number and a sum :D
[10:32] <jibel> sil2100, +1 for gallery app
[10:33] <sil2100> \o/
[10:33] <sil2100> Publishing
[10:35] <jibel> sil2100, you upload to the store as well?
[10:35] <sil2100> jibel: and what about the qtdeclarative5-ubuntu-ui-extras0.2 package in the end?
[10:35] <jibel> sil2100, it is wrong in vivid too. You have a click app that depends on an external lib that is not part of the framework but added manually to the seed
[10:36] <sil2100> jibel: hm, but I don't see it in ubuntu-rtm right now - will we need to land the camera-app silo first?
[10:36] <sil2100> rmadison says it's only in vivid currently
[10:37] <jibel> sil2100, it's in 17, bfiller said "No because gallery-app click package does not need ui-extras0.2 yet and we are not installing the gallery-app deb which has this dependency"
[10:38] <jibel> sil2100, I don't quite understand why the click package wouldn't need this lib
[10:39] <jibel> sil2100, the lib is not embedded in the click package, so if it is not installed on the system it'll use the wrong version
[10:39] <sil2100> Ah, hm
[10:39] <sil2100> Ok
[10:39] <jibel> sil2100, I don't know what in gallery app uses this lib and if it detects which version is available at runtime
[10:40] <jibel> sil2100, I think it's safer to wait for silo 17 to land too
[10:40] <sil2100> Not sure what to do in this case, as even though the .deb packages are basically just dummy ones, but this will mean I'll push a broken-dep package to the archive
[10:40] <sil2100> jibel: yeah
[10:40] <sil2100> Ok, let's just wait then :)
[10:40] <sil2100> Thanks!
[10:41] <jibel> sil2100, but IMO this lib should be a dependency of an ubuntu-sdk-lib-extras which would be a suggest of ubuntu-sdk-lib and -extras would be added to the seed. and if the version of the lib changes you bump the version of the framework
[10:43] <jibel> sil2100, probably cleaner than adding that lib manually to the seed. You cannot even track which click package depends on it, and that'll probably break stuff next time it's updated to a major version
[10:54] <psivaa_> popey: I've added your request to our 'To do' lane
[10:54] <psivaa_> Doing this should not take that long but it could be a little while for us to get there
[10:54] <psivaa_> s/there/to it
[10:54] <popey> thanks psivaa_
[10:54] <psivaa_> np
[11:28] <jibel> cihelp: on http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/krillin/239:20150218:20150216-fe747ac/332/ 3 tests are failing because system-settle failed (abook, dialer and calc) Where do I find info why it failed? There is not much info in top-before and top-after log files
[11:29] <sil2100> jibel: ogra_ had a nice script to parse it for useful information
[11:30] <jibel> ogra_, ^ do you mind sharing your script?
[11:30] <ogra_> paste.ubuntu.com/10289122/
[11:31] <ogra_> i havent used it in ages, not sure it still works
[11:31] <jibel> ogra_, I'll try, thanks!
[11:32] <vila> jibel: pas mieux
[11:34] <jibel> sil2100, ogra_ I don't see anything interesting in topafter but it's likely the scoperunner crash that generated the load
[11:35] <jibel> davmor2, did you notice any crash while testing the custom tarball?
[11:36] <davmor2> jibel: nope
[11:42] <sil2100> I go prepare lunch
[11:45] <rvr> popey: Calendar app: text: "W"+ root.startDay.weekNumber()
[11:45] <rvr> popey: "W" must be localized
[11:46] <rvr> popey: Also, pot file needs update, "All Day" is not available in Launchpad for translations.
[12:24] <Mirv> sil2100: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-005-1-build/112/console ...
[12:24] <Mirv> sil2100: I once ran build with watch_only quite quickly after uploading the final version, now it's like that..
[12:25] <sil2100> huh?
[12:25] <Mirv> sil2100: I guess just another way CI Train may "save" some wrong information and not clear that out
[12:25] <Mirv> sil2100: note how it checks two versions of the same package
[12:26] <sil2100> Mirv: yeah, probably try doing a normal non-watch_only build
[12:26] <sil2100> But I guess it's a bug indeed
[12:26] <sil2100> watch_only should not use any saved state for source packages
[12:26] <Mirv> sil2100: normal build same problem it seems https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-005-1-build/113/console
[12:27] <sil2100> huh
[12:27] <sil2100> Ok, now that's broken then
[12:27] <sil2100> Let me take a look in-between frying
[12:33] <sil2100> hm
[12:34] <sil2100> Mirv: from the CI Train side everything looks ok, I wonder what the new build job does
[12:35] <Mirv> sil2100: the old version is not even shown at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-005/+delete-packages anymore
[12:37] <popey> rvr: can you file a bug pls?
[12:38] <Mirv> sil2100: maybe it's still something that will sort itself by time, ie. the LP query will return different results at some point.
[12:38] <rvr> popey: Yes, we can
[12:39] <popey> thanks
[12:43] <rvr> popey: https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1423160
[12:43] <popey> thanks rvr
[12:57] <Mirv> sil2100: ok, it still failed I now did _both_ prepare-silo reconfig + tagged force_rebuild of both packages (even though they are manual uploads and not MP:s). either of them finally cleared the wrong info out.
[13:00] <sil2100> Mirv: geh, ok...
[13:18] <boiko> trainguards: question: the silo request on row 56 does not change existing code, just remove some toos that were not being used for quite some time on history-service, do I need to put QA signoff as Required still?
[13:28] <sil2100> boiko: I would say it shouldn't require sign-off, since the diff indeed looks sane
[13:28] <sil2100> boiko: but shouldn't you also remove history-service-tools from debian/control?
[13:28] <boiko> sil2100: well, that's the thing: on vivid we added new tools, I just don't want to backport them right now
[13:40] <sil2100> boiko: ok, yeah, but in ubuntu-rtm it would mean that we'll have an empty package basically, right?
[13:40] <sil2100> Not a super bad thing though
[13:41] <boiko> sil2100: yep, at least until we backport the new tools (they help testing, as they populate the history database, etc)
[13:54] <pete-woods> trainguards: hi, could I get vivid silo 011 reconfigured please? thanks!
[13:56] <Mirv> pete-woods: sure
[13:56] <sil2100> pete-woods: done
[13:56] <sil2100> Mirv: ^
[13:57] <Mirv> sil2100: hehe :)
[13:57] <Mirv> pete-woods: and thanks for the fix already in advance!
[13:57] <sil2100> boiko: ok, assigned the silo, but QA might want to re-discuss the requirement of sign-off
[13:58] <boiko> sil2100: that's fine, I was just trying to leverage their work :)
[14:00] <bfiller> jibel, sil2100: gallery-app click package does not depend on ui-extras0.2 yet so that is not needed technically
[14:00] <bfiller> it will need it in the future but doesn't right now
[14:00] <pete-woods> Mirv: well, importantly this won't be truly fixed until the apps are updated to stop doing their own translations for infographics (see MR for music-app https://code.launchpad.net/~unity-team/music-app/infographics-translations/+merge/248251)
[14:02] <bfiller> sil2100: kenvandine can ack the packaging changes in silo 18, he's aware of the situation
[14:02] <kenvandine> hey bfiller
[14:02] <sil2100> bfiller: ok... if a core-dev acks that then it's fine, but basically right now the deb will be uninstallable on ubuntu-rtm
[14:02] <sil2100> I know we don't use the .deb basically
[14:02] <kenvandine> sil2100, have you seen anything like this?  http://pastebin.ubuntu.com/10290989/
[14:03] <sil2100> But if something lands in the archive it should have archive-sufficient quality
[14:03] <bfiller> sil2100: yes that is true, but we don't use the deb at all. it's only there for convergence to install on desktop
[14:03] <sil2100> bfiller: I'll let kenvandine as the core-dev to decide ;)
[14:03] <bfiller> sil2100: so lets sync ui-extras then from vivid at the same time
[14:03] <sil2100> bfiller: yeah, it's in another silo which seems to have some problems currently
[14:04] <sil2100> Otherwise I would just sign-off and land both
[14:04] <bfiller> sil2100: we can move that into it's own silo so it can land independently
[14:04] <sil2100> bfiller: no worries, let's wait a bit on how things resolve and decide then if we need to hack around it
[14:04] <kenvandine> sil2100,  i'm fine acking that for rtm
[14:05] <kenvandine> we aren't running desktops from rtm anyway
[14:05] <bfiller> sil2100, kenvandine : ok thanks guys
[14:05] <sil2100> Ok then, let me publish it :)
[14:05] <kenvandine> thanks
[14:05] <kenvandine> sil2100, and look at that pastebin when you get a chance :)
[14:05] <sil2100> kenvandine: ok, looking now
[14:05] <jibel> bfiller, there is a fix for the camera, so it should land later today, and ui-extras0.2 too
[14:05] <kenvandine> that's what we're getting from smoke tests
[14:06] <kenvandine> sil2100, which i've reproduced on my krillin running vivid locally
[14:06] <sil2100> kenvandine: hm, now that's something I never saw before
[14:06] <kenvandine> also...
[14:06] <sil2100> kenvandine: it started happening after the u-s-s silo landed... was there anything risky in it?
[14:06] <kenvandine> this started happening between image 96 and 98
[14:06] <kenvandine> which had a massive mir landing
[14:06] <bfiller> jibel: ok cool, thanks
[14:07] <kenvandine> sil2100, there was also a mir landing
[14:07] <kenvandine> there was nothing risky in the silo
[14:07] <kenvandine> sil2100, in fact... the only change in that silo was adding some UI that is hidden
[14:07] <sil2100> kenvandine: but not in ubuntu-rtm - and we see the same failures in rtm with the latest image
[14:07] <kenvandine> wait... same thing in rtm?
[14:08] <sil2100> kenvandine: http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/krillin/239:20150218:20150216-fe747ac/332/ <- this is the latest result in rtm after landing of the u-s-s silo, no failures seen before this
[14:08] <sil2100> http://people.canonical.com/~lzemczak/landing-team/ubuntu-rtm/239.commitlog
[14:08] <sil2100> These are the changes
[14:08] <kenvandine> sil2100, so the same change landed in rtm, and the UI isn't hidden there
[14:09] <sil2100> This is why I started thinking that it's this landing that's responsible
[14:09] <kenvandine> sil2100, what image did it start happening in for rtm?
[14:09] <sil2100> WIth this one
[14:09] <sil2100> 239
[14:09] <kenvandine> that is the latest right?
[14:09] <sil2100> http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/ <- all others have normal failure counts
[14:09] <sil2100> Yes :)
[14:09] <kenvandine> well wtf@
[14:09] <sil2100> We would really like to have this resolved as it's blocking our promotion
[14:10] <kenvandine> sil2100, the change we landed in 239 also landed yesterday in vivid
[14:10] <sil2100> Since releasing OTA-1 with so many failures is really bad ;p
[14:10] <kenvandine> this has been happening for over a week in vivid
[14:10] <sil2100> hmm
[14:10] <sil2100> Interesting
[14:10] <bfiller> sil2100: I will push the gallery-app click to the store now, is that ok?
[14:11] <kenvandine> sil2100, and... the only change in the image that this was introduced in with vivid had landed in rtm a week before it landed in vivid
[14:12] <seb128> kenvandine, hey, getting anywhere with the u-s-s test issue?
[14:12] <kenvandine>  #15 0xaf0763ce in QFeedbackHapticsEffect::QFeedbackHapticsEffect(QObject*) () from /usr/lib/arm-linux-gnueabihf/libQt5Feedback.so.5
[14:12] <kenvandine> same damn thing
[14:13] <kenvandine> seb128, that's what sil2100 and i are talking about
[14:13] <kenvandine> seb128, it just started happening in rtm smoke testing
[14:13] <seb128> kenvandine, weird
[14:13] <kenvandine> in image 239
[14:13] <sil2100> brb
[14:13] <kenvandine> seb128, and there are strange logs
[14:14] <kenvandine> http://pastebin.ubuntu.com/10290989/
[14:14] <kenvandine> seb128, ^^ thoughts?
[14:14] <seb128> kenvandine, not really, does it have to do with screencasting?
[14:15] <seb128> how is the screencasting working?
[14:15] <kenvandine> oh i wonder if that is what's causing that log
[14:15] <kenvandine> i don't know
[14:15] <seb128> can we enable it locally to see if we hit the same issue?
[14:16] <kenvandine> i have reproduced it locally
[14:16] <kenvandine> on my krillin with vivid
[14:16] <kenvandine> oh
[14:16] <kenvandine> that can't be screencasting
[14:16] <kenvandine> i get that same log output locally
[14:16] <seb128> k
[14:16] <kenvandine> [1424235205.472568] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in setSwapInterval): /build/buildd/mir-0.11.0+15.04.20150209.1/src/client/buffer_stream.cpp(283): Throw in function virtual void mir::client::BufferStream::request_and_wait_for_configure(MirSurfaceAttrib, int)
[14:16] <kenvandine> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt11logic_errorEEEE
[14:17] <kenvandine> that part anyway
[14:17] <seb128> did mir change in rtm?!
[14:17] <kenvandine> seb128, and at the same time, there's a seg fault from uss that seems to be triggered by haptic feedback
[14:17] <kenvandine> seb128, i don't think so
[14:17] <kenvandine> not in image 239
[14:17] <seb128> weird
[14:18] <kenvandine> seb128, but... there was a mir landing in the first vivid image that had this problem
[14:18] <seb128> doesn't explain why rtm get the same issue without a mir landing
[14:18] <kenvandine>  qtdeclarative5-ubuntu-ui-toolkit-plugin changed in image 236
[14:20] <kenvandine> seb128, the good news is this crash really happens at the very beginning of the test
[14:20] <kenvandine> everytime
[14:20] <kenvandine> and we aren't seeing this crash manually testing
[14:21] <kenvandine> so it must be something to do with the autopilot tests
[14:21] <kenvandine> and i've ruled out infrastructure by testing locally
[14:22] <kenvandine> i wonder if we're the only ones seeing this because we don't use upstart-app-launch
[14:35] <kenvandine> seb128, https://errors.ubuntu.com/problem/b4ceece27f0ccfe9753e940695015237461b3908
[14:35] <seb128> kenvandine, not very useful, why isn't retracing working?
[14:36] <bfiller> popey: can your review/ack new gallery I just uploaded to store?
[14:36] <kenvandine> seb128, that's what i was going to ask you :)
[14:36] <seb128> bdmurray, ^ can you help there?
[14:37] <popey> bfiller: done
[14:38] <kenvandine> also... all 3 instances of it where run by autopilot
[14:39] <kenvandine> seb128, https://errors.ubuntu.com/problem/f1aceaefc06bcc522f22df201625eb2d111929fb
[14:39] <kenvandine> that one has a retrace
[14:40] <sil2100> Publishing o/
[14:40] <seb128> kenvandine, right, who is working on the feedback plugin?
[14:40] <kenvandine> that's from qt
[14:41] <sil2100> bfiller: anyway, can you please upload the new gallery-app to the store? :)
[14:41] <kenvandine> seb128, i'd think that would affect all kinds of stuff
[14:41] <kenvandine> we don't do anything directly there
[14:41] <kenvandine> just the uitk
[14:42] <kenvandine> seb128, i created bug 1423205
[14:43] <bfiller> sil2100: done, popey just approved it
[14:43] <sil2100> Excellent
[14:44] <bfiller> sil2100: can I get a silo for line 58 on vivid, it's the camera-app fix need to land it in vivid first then will sync to rtm
[14:44] <sil2100> Sure, on it
[14:44] <bfiller> jibel: ^^^ the camera-app is fixed, just doing the vivid landing first then will update the rm silo
[14:44] <bfiller> rtm silo
[14:46] <om26er> kenvandine, Hi!
[14:47] <om26er> kenvandine, I am trying out silo 14. If the device does not discover the bluetooth name of the headset, it shows its MAC address, is it supposed to keep showing that until I connect to the headset ?
[14:48] <kenvandine> as long as it doesn't detect a name
[14:48] <kenvandine> it should
[14:48] <jibel> bfiller, OK, rhuddie ^ can you reverify the camera after silo 3?
[14:48] <om26er> kenvandine, how long does it take to detect the name generally ?
[14:48] <kenvandine> om26er, it might never
[14:48] <jibel> rhuddie, when it's in the silo of course :)
[14:48] <kenvandine> that was part of the problem
[14:48] <kenvandine> it would display an empty name
[14:48] <kenvandine> s/part//
[14:49] <rhuddie> jibel, sure. i just finished silo 3.
[14:49] <om26er> kenvandine, I think we need to add a testcase to the testplan for this bug fix.
[14:49] <kenvandine> om26er, so you have a device that doesn't get a name?
[14:49] <bfiller> rhuddie: I'll ping you soon when it's in the rtm silo
[14:49] <om26er> kenvandine, it showed its MAC address
[14:49] <rhuddie> bfiller, thanks.
[14:49] <kenvandine> om26er, to properly test this specific case, the tester needs a device that wouldn't show a name
[14:50] <om26er> hmmm, don't have that.
[14:50] <kenvandine> om26er, i don't have a device that doesn't show a name
[14:51] <om26er> kenvandine, let me clear there are three cases ? 1. where name is shown. 2. only MAC address, 3. No nothing and in that case we want to show "..." ?
[14:51] <kenvandine> om26er, for case 3 we want to show the address
[14:52] <kenvandine> om26er, it should only show the address when there is no name detected
[14:52] <kenvandine> om26er, i don't have any devices that don't show a name
[14:52] <kenvandine> for example
[14:53] <kenvandine> om26er, so showing the address shouldn't be common, i'd hope
[14:53] <om26er> I tried it in my car it showed the MAC address, the name only appeared when I connected to it.
[14:53] <kenvandine> om26er, cool, i think that's what we want
[14:53] <kenvandine> om26er, but there are some devices that'll never get a name
[14:54] <kenvandine> so we'll keep showing the address
[14:54] <kenvandine> om26er, but to test that you need a device that doesn't get the name
[14:54] <kenvandine> not sure we want to require everyone that tests this to have such a device
[14:55] <om26er> heh, I'll just approve it after some more testing.
[14:56] <kenvandine> om26er, thx... not sure how to test it
[14:56] <kenvandine> we tested it for regressions
[14:56] <kenvandine> well, pmcgowan did, not sure if he had a device that didn't detect the name or not
[14:57] <kenvandine> i tested it in vivid, all my devices still show the name
[14:58] <pmcgowan> kenvandine, om26er  my device initially shows the address, then when connnected switches to the name
[14:59] <kenvandine> pmcgowan, and is that the same behavior as before?
[14:59] <pmcgowan> kenvandine, before the field was blank the the first page, now it shows the address
[15:00] <kenvandine> pmcgowan, perfect!
[15:00] <kenvandine> so you have a device that reproduced the bug :)
[15:00] <kenvandine> pmcgowan, i tried everything in my house that has bluetooth... they all show a name before connecting
[15:01] <pmcgowan> yeah my headset showed the issue, whereas my car showed the name
[15:01] <pmcgowan> probably a bt version thingy
[15:02] <pmcgowan> sil2100, jibel  any chance we will get all the queued silos landed?
[15:03] <sil2100> pmcgowan: yes, although we might still be blocked on the failing autopilot tests for ubuntu-system-settings anyway
[15:03] <sil2100> pmcgowan: since currently we have almost all u-s-s tests failing
[15:03] <om26er> kenvandine, looking at the diff, previously if device was not paired you appended "..." now you are doing that for the opposite. Intentional ?
[15:03] <jibel> pmcgowan, all the critical fixes will land (9, 14, calendar and camera are under verification)
[15:03] <sil2100> kenvandine is looking into that
[15:03] <sil2100> pmcgowan: btw. did you hear anything about us not to include calendar-app?
[15:04] <ogra_> hmm
[15:04]  * ogra_ wonders why rmadison gives him 503 errors
[15:04] <jibel> pmcgowan, we'll maybe have time to land silo 1, depending how it goes with silos under testing.
[15:05] <pmcgowan> jibel, silo 0 is also a customer report fix
[15:05] <pmcgowan> and silo 20 just looks like great fixes
[15:06] <pmcgowan> but gotta stop sometime
[15:06] <sil2100> pmcgowan: but 0 doesn't seem to look ready
[15:06] <jibel> pmcgowan, but it is not ready for QA. last comment from rsalveti is "Not yet to be validated, WIP (had tested as yes by accident)."
[15:06] <pmcgowan> ok
[15:06] <rsalveti> pmcgowan: jibel: yeah, we found one issue with silo 0, working on the fix
[15:06] <rsalveti> so not completely ready yet
[15:07] <kenvandine> om26er, indeed that does look opposite... cyphermox ^^
[15:07] <kenvandine> om26er, good eye...
[15:08] <pmcgowan> sil2100, I did not hear anything about calendar app
[15:08] <sil2100> pmcgowan: since I was wondering how to include it and cwayne mentioned something about Joe saying not to add it yet
[15:08] <kenvandine> cyphermox, before you only appended "..." if it wasn't paired, now you're only appending it if it is paired
[15:08] <sil2100> But I wonder what that means
[15:08] <pmcgowan> let me check
[15:09] <cyphermox> kenvandine: indeed, it's a logic error
[15:09] <kenvandine> cyphermox, can you fix that up quickly?
[15:09] <pmcgowan> sil2100, last email I have on this joe just says keep him posted
[15:09] <kenvandine> we really want to land that today
[15:10] <kenvandine> om26er, i'll rebuild that silo as soon as cyphermox fixes that
[15:10] <kenvandine> om26er, thanks for catching that!
[15:10] <om26er> kenvandine, ok sure ;-)
[15:10] <cyphermox> kenvandine: pushed
[15:10] <kenvandine> cyphermox, thx!
[15:11] <kenvandine> cyphermox, i'll fix it for trunk
[15:11] <cyphermox> k
[15:11] <jibel> pmcgowan, this is what we found with the calendar app so far: bug 1423185, bug 1423191, bug 1423209, bug 1362781, bug 1347836
[15:11] <cwayne> pmcgowan: sil2100: just got a hard -1 on adding calendar
[15:11] <pmcgowan> cwayne, ok
[15:11] <sil2100> cwayne: oh? What's up?
[15:11] <pmcgowan> all those bugs
[15:11] <pmcgowan> jibel, thanks
[15:12] <sil2100> jibel: thanks!
[15:12] <jibel> pmcgowan, I don't see it in the list but event syncs doesn't work reliably
[15:13] <pmcgowan> jibel, how so?
[15:13] <jibel> pmcgowan, someone in the team reported that this morning during our standup, I'll find the bug
[15:16] <alan_g> plars: Are there problems on mir-mediumtests-runner-mako? Just had this twice "Rebooting the phone will take approximately 30 seconds to settle/Build timed out (after 60 minutes). Marking the build as failed."
[15:16] <plars> alan_g: not that I've heard of, but I'm just coming on. Can you point me at the job?
[15:17] <alan_g> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/4328/console (and 4389)
[15:17] <cwayne> sil2100: it's a bit too risky to add a new app this late in the game
[15:19] <kenvandine> cyphermox, mind an ack? https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/address-not-name-rtm-logic-error/+merge/250152
[15:19] <plars> alan_g: on a standup right now, give me just a bit and I'll take a look
[15:19] <jibel> bfiller, any ETA for the update of the camera app in RTM?
[15:19] <alan_g> plars: ok
[15:19] <cyphermox> kenvandine: thar.
[15:20] <kenvandine> cyphermox, thx
[15:20] <bfiller> jibel: within 30 minutes, landing in vivid currently
[15:20] <jibel> bfiller, thanks
[15:29] <bfiller> sil2100: mind publishing ubuntu silo 27 for camera-app
[15:30] <om26er> bzoltan_, Hi!
[15:31] <om26er> bzoltan_, I can't select text in unity' searchbar with silo1, the actionbox takes over the selector.
[15:32] <om26er> more like the handlers hide
[15:35] <jhodapp> sil2100, can I get a silo for line 59 please
[15:37] <om26er> kalikiana, ^
[15:40] <bdmurray> seb128, kenvandine: this is the log file portition for the retrace attempt - https://pastebin.canonical.com/125821/
[15:41] <bdmurray> pitti might have more information about why retraces fail like that
[15:41] <kenvandine> bdmurray, thx for looking
[15:41] <kenvandine> i found a retrace
[15:42] <seb128> bdmurray, thanks
[15:42] <bdmurray> kenvandine: where?
[15:42] <kenvandine> https://errors.ubuntu.com/problem/f1aceaefc06bcc522f22df201625eb2d111929fb
[15:44] <jhodapp> cyphermox, can I get a silo for line 59 please?
[15:45] <cyphermox> jhodapp: sure
[15:45] <jhodapp> cyphermox, looks like i jsut got on, thanks anyway
[15:45] <jhodapp> sil2100, thanks man!
[15:45] <bfiller> rhuddie: here is the update click to test for silo 17: https://jenkins.qa.ubuntu.com/job/generic-click-builder-vivid-armhf/342/artifact/output/com.ubuntu.camera_3.0.0.514_armhf.click
[15:46] <rhuddie> bfiller, jibel, thanks. I'll start testing
[15:47] <kenvandine> sil2100,  you can rest easier... the always awesome jgdx has a fix for the smoke test failures!
[15:47] <kenvandine> and it's just in the autopilot tests
[15:47] <kenvandine> nothing wrong with settings itself
[15:47] <sil2100> Oh OOH!
[15:47] <sil2100> :D
[15:48] <kenvandine> it actually removes one test :/
[15:48] <kenvandine> but that one test blows the entire suite
[15:49] <kenvandine> we're not 100% sure why yet... but something to do with the session bus
[15:52] <kenvandine> sil2100, we're still investigating a proper fix that wouldn't make us remove that test
[15:54] <sil2100> jibel: ^
[15:54] <sil2100> kenvandine: what test needs removing to fix the suite?
[15:58] <kenvandine> sil2100, it's the ConnectivityMixin class that's causing the problems, which is needed by test_sim_unlock
[15:59] <sil2100> jibel: ^ do you it is acceptable to temporarily get rid of the test for this release to make all the other tests working again?
[15:59] <kenvandine> sil2100, jibel: and the problem with the test has nothing to do with a feature regression...
[15:59] <kenvandine> it's just problems with the session bus
[16:00] <kenvandine> and the uitk using the session bus to get the vibrate settings
[16:01] <kenvandine> om26er, silo 14 is built again
[16:01] <om26er> kenvandine, thanks, will test that in a bit
[16:01] <kenvandine> -            if (device->isPaired())
[16:01] <kenvandine> 9	+            if (!device->isPaired())
[16:01] <kenvandine> om26er, the only diff
[16:01] <om26er> yeah I saw that.
[16:01] <kenvandine> om26er, thx
[16:02] <sil2100> kenvandine: anyway, I'd like QA to decide if we can go with that, but seeing how things are going I suppose that's our only choice
[16:02] <om26er> kenvandine, approved.
[16:02] <sil2100> If we intend to get an image ready by the end of the UTC day
[16:02] <kenvandine> om26er, thx!
[16:06] <sil2100> kenvandine: ouch...
[16:06] <sil2100> kenvandine: I can't publish silo 14 as there was a release in the meantime
[16:06] <sil2100> So we might need to rebuild the silo ;/
[16:06] <kenvandine> what?
[16:06] <kenvandine> i just rebuilt it
[16:06] <kenvandine> oh
[16:06] <kenvandine> i already published it :)
[16:07] <kenvandine> sil2100, sorry... that broke you :)
[16:07] <sil2100> Ahah
[16:07] <sil2100> :D
[16:07] <kenvandine> sil2100, i'll prepare a silo dropping that test, in case we want to land that
[16:07] <sil2100> Right, I always forget you publish your own silos :D
[16:07] <sil2100> kenvandine: yes, please
[16:08] <kgunn> sil2100: hey so your mail, are you saying gate is closed even for things that were ready tues morning...but in the qa test queue ?
[16:09] <bzoltan_> om26er:  if you have any problems or question related to the silo1,  please feel free to reach out :)
[16:09] <sil2100> kgunn: the gates are closed for new things, but not all silos prepared before the deadline will make it as it depends on QA capabilities ;)
[16:09] <om26er> bzoltan_, I did already :)
[16:10] <sil2100> kgunn: the highest priority are silos with critical or factory fixes
[16:10] <kgunn> got it...
[16:10] <sil2100> Others will land if QA is able to sign-off
[16:10] <om26er> bzoltan_, I can't select text in unity' searchbar with silo1, the actionbox takes over the selector.
[16:10] <kgunn> ours is under qa test atm
[16:10] <om26er> bzoltan_, http://i.imgur.com/xse3evb.png
[16:12] <kenvandine> sil2100, we're going to hold off proposing that for trunk though, so vivid smoke testing will remain broken for now
[16:12] <kenvandine> while we find a proper fix
[16:12] <kenvandine> that way we don't forget to fix it :)
[16:13] <jibel> kenvandine, sil2100 do we know exactly why the tests are failing?
[16:13] <sil2100> kenvandine: hm, ok, makes sense, even though I think it would be best if this gets fixed ASAP anyway since for quality we need to make sure that all automated tests work as they should
[16:15] <kenvandine> sil2100, yes... jgdx is working on it now
[16:16] <kenvandine> jibel, a test in our security panel starts a session bus
[16:16] <kenvandine> jibel, but now the uitk is needing the session bus so it gets started already
[16:16] <kenvandine> we're getting conflicting session buses
[16:16] <kenvandine> we think
[16:16] <kenvandine> jibel, so removing that ConnectivityMixin class we have, prevents that from happening
[16:17] <kenvandine> jibel, once it blew up, everything after it fails
[16:17] <kenvandine> we only need to remove it from the one test
[16:17] <jibel> kenvandine, OK, can you update the silo?
[16:18] <kenvandine> jibel, i just created a silo with it
[16:18] <kenvandine> jibel, we're leaving it broken in vivid for now
[16:18] <kenvandine> to keep the pressure on a proper fix
[16:18] <sil2100> kenvandine: remember that we first need the other u-s-s silo to merge-and-clean fully
[16:18] <kenvandine> sil2100, yes...
[16:18] <kenvandine> not building until then
[16:18] <bzoltan_> kalikiana: ping
[16:18] <sil2100> Excellent :)
[16:18] <jibel> kenvandine, fine, it's better than being completely blind
[16:19] <kalikiana> bzoltan_: pong
[16:19] <kenvandine> jibel, right... we know it isn't a real failure, just causing all hell to blow up in the test :)
[16:19] <bzoltan_> kalikiana:  om26er sees this http://i.imgur.com/xse3evb.png
[16:19] <bzoltan_> om26er:  what version of the UITK you have on the device?
[16:20] <kalikiana> bzoltan_: hmmm the handlers are missing?
[16:20] <bzoltan_> kalikiana: yes indeed
[16:20] <om26er> bzoltan_, 1.1.1298+15.04.20150218~rtm-0ubuntu1
[16:20] <kalikiana> om26er: how did you select that text?
[16:21] <om26er> kalikiana, double tap
[16:25] <bfiller> kenvandine: any way to speed up landing camera-app which is in proposed? http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=camera
[16:25] <bfiller> itching to rebuild sync silo
[16:25] <kalikiana> om26er: hmm can repro. and it's indeed the change to blame… no idea, though, what is happening, never seen that
[16:25] <kenvandine> bfiller, no... i don't think so
[16:26] <bfiller> kenvandine: like watching paint dry
[16:26] <kenvandine> bfiller, it usually takes about an hour
[16:26] <kenvandine> yeah
[16:26] <bfiller> ok
[16:27] <kenvandine> bfiller, why aren't you on the slopes?
[16:27] <kenvandine> if it's because of  camera-app, i can help :)
[16:27] <bfiller> kenvandine: going this afternoon :)
[16:28] <plars> alan_g: Looks like it was a weird fluke with that device, but the device seems fine now. I've restarted the job and I'll continue to monitor it
[16:30] <alan_g> plars: thanks
[16:30] <kalikiana> om26er: bzoltan_ I'll need to look into what unity is doing there. it has a custom clear button for some reason, but that doesn't easily explain this funny bug.
[16:31] <om26er> kalikiana, ok, i'll fail the silo for now.
[16:33] <bzoltan_> om26er: please hold a bit
[16:35] <om26er> bzoltan_, ok, moved back.
[16:37] <sil2100> davmor2: you signing-off location-service?
[16:38] <sil2100> Are we ok with getting a risky component like that in this milestone?
[16:39] <jibel> sil2100, it's in OTA1 priorities
[16:40] <sil2100> It was? hmmm
[16:40] <davmor2> sil2100: factory bug for battery drain aiui jibel okayed it
[16:40] <sil2100> I missed it completely
[16:41] <sil2100> jibel, davmor2: hm, the spreadsheet doesn't mention it as being reported by BQ/CKT
[16:42] <davmor2> sil2100: the battery drain general bug is though and this is a sub branch from that
[16:55] <rhuddie> bfiller, is there an update required on the rtm silo for the camera-app fix?
[16:56] <bfiller> rhuddie: we should rebuild the camera-app deb once it lands in vivid but stuck in proposed
[16:56] <jhodapp> sil2100, not sure what happened here, any insight? https://ci-train.ubuntu.com/job/ubuntu-landing-028-1-build/23/console
[16:56] <bfiller> rhuddie: since we don't use the deb it can probably land as is if all the testing done
[16:57] <bfiller> rhuddie: I just need to upload the click you tested to the store
[16:57] <jhodapp> sil2100, actually nevermind, the more detailed logs for each ARCH point out what's wrong
[16:57] <sil2100> jhodapp: it seems the packages failed to build in the PPA
[16:58] <jhodapp> sil2100, yeah, missing build dep
[16:58] <rhuddie> bfiller, this click is giving me a problem loading the app
[16:58] <bzoltan_> om26er:  I pull off that MR from the landing silo and leave the oneliner to fix the other bug. If you culd wait a half an hour
[16:58] <bfiller> rhuddie: what do you mean?
[16:59] <om26er> bzoltan_, sure thing.
[16:59] <rhuddie> bfiller, well, I've installed it with the silo updates, when I launch it, I see the camera screen load briefly and then it disappears
[16:59] <bzoltan_> om26er:  at least we ship two bugfixes with this round
[17:00] <bfiller> rhuddie: I'm not seeing that, anything in the log? ~/.cache/upstart/application-click-com.ubuntu.camera_<version>.log
[17:01] <plars> alan_g: it's looking like my retry is going to suffer the same fate - I think it could be your change that's killing it
[17:02] <plars> alan_g: it's on a different device this time, and it was fine after the base install, but not after installing your update and rebooting
[17:02] <alan_g> plars: I'll take another look at it
[17:04] <kenvandine> bfiller, i feel your pain, i'm watching paint dry too.. with settings
[17:04]  * kenvandine twiddles thumbs
[17:04] <bfiller> rhuddie: I'm seeing the issue, checking the problem
[17:05] <rhuddie> bfiller, this is my log: http://pastebin.ubuntu.com/10293406/
[17:09] <bfiller> Kaleo: the click for camera-app that was built by jenkins has some issues, getting undefined symbols
[17:09] <bfiller> Kaleo: see rhuddie log above, I'm seeing the same
[17:10] <bfiller> Kaleo: did something change in qtubuntu-camera in vivid that is needed now in RTM?
[17:31] <Kaleo> bfiller, dunno of that, but we changed only one line since you last built a click
[17:31] <Kaleo> bfiller, checking
[17:31] <bfiller> Kaleo: I just rebuilt the click, trying that now.
[17:32] <Kaleo> bfiller, it looks nothing like any change that may have been made to any of the code
[17:32] <Kaleo> bfiller, it looks more like something in the build env that has changed
[17:33] <Kaleo> bfiller, it's the first time we actually use the camera click pkg produced by jenkins no?
[17:33] <Kaleo> bfiller, usually we build it ourselves IIRC
[17:33] <Kaleo> bfiller, both for testing and publishing
[17:34] <bfiller> Kaleo: we always use jenkins, ok here is a new one I built with jenkins seems to work http://people.canonical.com/~bfiller/com.ubuntu.camera_3.0.0.515_armhf.click
[17:34] <bfiller> Kaleo: please verify to make sure that has nerochiaro's change and that it's working correctly
[17:35] <Kaleo> bfiller, you built that one *with* jenkins?
[17:35] <bfiller> Kaleo: yes, but did it manually and didn't take the one jenkins built via CI
[17:35] <Kaleo> bfiller, I see
[17:35] <bfiller> not sure what the difference is but the app launches now :)
[17:35] <bfiller> rhuddie: http://people.canonical.com/~bfiller/com.ubuntu.camera_3.0.0.515_armhf.click
[17:35] <Kaleo> bfiller, ok
[17:38] <mzanetti> trainguards: can someone please rebuild qtsystems in silo0 for me?
[17:39] <robru> mzanetti: do you not have permission?
[17:39] <mzanetti> robru: afaik I can't no, because it's not added via the spreadsheet but uploaded manually
[17:39] <robru> mzanetti: oh, hrm.
[17:39] <mzanetti> I might be wrong...
[17:39] <robru> mzanetti: so what, you need a no-change rebuild? you don't have a change to apply to it?
[17:39] <mzanetti> I pushed to the branch
[17:40] <mzanetti> oh, I see
[17:40] <mzanetti> one sec :)
[17:40] <mzanetti> robru: lp:~mzanetti/ubuntu/vivid/qtsystems-opensource-src/inputinfo
[17:41] <robru> mzanetti: oh ok, yeah I can upload that, one sec.
[17:41] <mzanetti> thanks
[17:41] <bzoltan_> om26er:  the silo1 is ready .. I ripped off the cursor "fix"
[17:42] <om26er> bzoltan_, thanks for that, I'll repick it after a few minutes. In a meeting right now.
[17:42] <nerochiaro> bfiller: Kaleo: i tested the image you linked and it seems to have my change and be working ok
[17:42] <bzoltan_> om26er:  OK, thanks for your patinece
[17:43] <Kaleo> nerochiaro, by image you mean click?
[17:43] <nerochiaro> Kaleo: sorry yes
[17:43] <Kaleo> bfiller, nerochiaro: I have tested the manually built click 515 and it works too
[17:44] <kenvandine> sil2100, is there an excuses page for rtm?
[17:44] <kenvandine> sil2100, it's taking unusually long for settings to make it to release
[17:44] <sil2100> kenvandine: yeah, one moment
[17:44] <sil2100> ugh
[17:44] <sil2100> Wait, wtf, it's gone
[17:45] <robru> mzanetti: what do you want in the changelog? eg what did you change?
[17:45] <sil2100> aaaha
[17:45] <sil2100> nvm
[17:45] <sil2100> kenvandine: http://people.canonical.com/~ubuntu-archive/proposed-migration/ubuntu-rtm/14.09_update_excuses.html
[17:45] <sil2100> hmm
[17:45] <kenvandine> sil2100, hmmm settings isn't on that
[17:45] <sil2100> it's outdated
[17:45] <kenvandine> oh... indeed
[17:45] <kenvandine> is something not running?
[17:46] <sil2100> cjwatson: are there any known problems with 14.09 migration right now?
[17:46] <sil2100> slangasek: ^ ?
[17:47] <robru> mzanetti: nm, got your commit message
[17:48] <slangasek> sil2100: I've just committed a merge of some changes from cjwatson to proposed-migration, could be related
[17:48] <cjwatson> sil2100: Heh, somebody merged my branches but one of them was deployed slightly differently live, so conflict
[17:48] <cjwatson> I'll fix
[17:48] <slangasek> oops
[17:48] <kenvandine> :)
[17:48] <slangasek> "deployed slightly differently live"?
[17:48] <kenvandine> cjwatson, thanks!
[17:48] <cjwatson> I deployed an earlier version of the output-prefix stuff because it was urgent for 14.09-factory
[17:48] <kenvandine> sil2100, i've been anxiously watching it so i could build that silo for you :)
[17:49] <robru> mzanetti: ok, new upload building, should be good to go
[17:49]  * cjwatson replaces with the committed version
[17:49] <cjwatson> sil2100: should work next time, thanks
[17:50] <cjwatson> slangasek: thanks for the merges
[17:50] <sil2100> kenvandine: ;)
[17:50] <slangasek> cjwatson: sure thing
[17:50] <sil2100> Thanks for fixing!
[17:50] <cjwatson> I guess I'd better run them by hand to catch up
[17:50] <sil2100> kenvandine: we'll spin a new image as soon as the current u-s-s migration finishes
[17:50] <kenvandine> cjwatson, that would be appreciated
[17:50] <sil2100> kenvandine: we can include the autopilot fixes later
[17:51] <kenvandine> sil2100, sure
[17:51] <sil2100> (as those don't require testing by QA anyway)
[17:51] <kenvandine> sil2100, ah... can you change that on the spreadsheet then?
[17:51] <kenvandine> i put required
[17:52] <sil2100> Sure
[17:52] <kenvandine> sil2100, thx
[17:52] <cjwatson> eek, this is crashing hard
[17:52]  * cjwatson disables archive-reports while he debugs
[17:52] <rhuddie> bfiller, Kaleo, thanks. confirm this version is now working and I get video thumbnail. One bug I've noticed is that the new photo-roll Edit option is enabled for videos, as well as photos
[17:54] <bfiller> rhuddie: that is indeed a bug
[17:54] <Kaleo> bfiller, shall we disable editing? :)
[17:54] <bfiller> Kaleo: if we don't seed qtdeclarative5-ubuntu-ui-extras0.2 then it will be disabled
[17:54] <Kaleo> bfiller, right
[17:55] <Kaleo> bfiller, is it seeded in vivid?
[17:55] <Kaleo> bfiller, it's not seeded anywhere atm right?
[17:55] <bfiller> Kaleo: it's seeded in vivid but not in rtm
[17:55] <Kaleo> bfiller, so we need to fix the bug regardless
[17:56] <bfiller> Kaleo: lets just fix it, should be simple
[17:56] <Kaleo> bfiller, ugo said it's prob easy
[17:56] <bfiller> we do the same already in gallery-app
[17:56] <Kaleo> bfiller, good, was gonna asxk
[17:56] <cjwatson> sil2100,kenvandine: should be happier now
[17:56] <Kaleo> -x
[17:57] <Kaleo> rhuddie, fixing now, should be a one liner :)
[17:57] <sil2100> cjwatson: yaay, thanks ;)
[17:57] <cjwatson> sil2100: note it's now http://people.canonical.com/~ubuntu-archive/proposed-migration/ubuntu-rtm/14.09/update_excuses.html, sorry for the rearrangements - I'll put symlinks or redirects or something in place in a bit
[17:57] <cjwatson> another reason I want to do a couple of runs by hand
[17:58] <rhuddie> Kaleo, thanks. I'm going to be eod soon, so somebody else will pick this one up again
[17:58] <Kaleo> rhuddie, understood, thanks
[17:58] <Kaleo> rhuddie, do you know who?
[18:01] <rhuddie> Kaleo, not yet. I'll update the card on the trello board with status. depends on how soon the next regression run starts.
[18:01] <Kaleo> rhuddie, any idea when that might be?
[18:01] <Kaleo> rhuddie, I mean, are we talking minutes hours or days?
[18:02] <rhuddie> Kaleo, well i believe new build should be within 2 hours
[18:02] <Kaleo> rhuddie, ah ok
[18:06] <kenvandine> cjwatson, thanks
[18:07] <kenvandine> sil2100, settings is in release now and i started building silo 11 for the test fix
[18:18] <om26er> bzoltan_, how can i verify fix for #1395118 ?
[18:19] <bzoltan_> om26er:  there is a demo code in the bug report
[18:20] <om26er> bzoltan_, if i put that into a .qml how can i launch it ?
[18:21] <bzoltan_> om26er:  just open the Ubuntu SDK, create a simple UI template app and copy that code over the main.qml
[18:30] <sil2100> kenvandine: thanks!
[18:30] <sil2100> Ok, let me check proposed and build a new image
[18:31] <sil2100> kenvandine: ok, so we have gallery-app stuck in -proposed because of missing qtdeclarative5-ubuntu-ui-extras0.2 , but we have a click for that anyway
[18:31] <kenvandine> yeah
[18:50] <imgbot> [18:58] <pmcgowan> boiko, sil2100 are we able to land silo 15? that has the last critical fixes
[18:58] <sil2100> pmcgowan: too late
[18:58] <pmcgowan> sil2100, those are factory fixes, so maybe not
[18:59] <sil2100> pmcgowan: the silo is still not set as ready...
[18:59] <boiko> pmcgowan: testing it
[18:59] <sil2100> pmcgowan: and we really need time to test the image, I already kicked off the first promotion candidate
[19:00] <pmcgowan> sil2100, I understand but won't matter if factory doesnt accept it
[19:00] <pmcgowan> john-mcaleely, ^^ what do you think
[19:00] <pmcgowan> sil2100, we can start testing then consider poking that one silo in
[19:00] <sil2100> hm, we can get a new one re-spinned later I guess
[19:01] <pmcgowan> sil2100, remember that was our plan to consider factory fixes late
[19:01] <john-mcaleely> sil2100, delay gets my vote, or land it late after QA with some retesting of that area?
[19:01] <sil2100> I'm a bit worried with the tight timeline, but yeah
[19:02] <john-mcaleely> pmcgowan, ^ as we discussed, I htink
[19:02] <pmcgowan> agreed, lets get it ready for QA then decide
[19:02] <john-mcaleely> yeah, nothing to be done until that state is reached
[19:02] <sil2100> Since it's ofono-related then I would actually wait with testing until it lands
[19:03] <sil2100> As it would require retesting a lot of things anyway
[19:04] <john-mcaleely> makes sense
[19:04] <pmcgowan> right agreed
[19:04] <sil2100> boiko: how does it look so far? You think it will be ready for sign-off in the nearest hours?
[19:05] <sil2100> I'll have to disconnect in a few, but I'll get back in around 2 hours in case an image needs to be built
[19:07] <sil2100> ToyKeeper: hey! Just so you know, if you see silo 15 as ready for sign-off please take care of it with priority ;)
[19:07] <sil2100> robru: ^ and if you could publish it with priority as well
[19:07] <robru> sil2100: sure thing
[19:07] <sil2100> Thanks :)
[19:07] <ToyKeeper> sil2100: Does that mean 240 isn't the promotion candidate, but 241 is?
[19:08] <boiko> sil2100: yep, it is looking good so far, should be ready for signoff pretty soon
[19:08] <sil2100> ToyKeeper: yeah, basically 241 will be the image we'd like to release
[19:09] <sil2100> kenvandine: ^ looks like your u-s-s autopilot fixes will still land in the promotion candidate ;)
[19:13] <rsalveti> triggering a new vivid for the new pulseaudio
[19:13] <kenvandine> Ran 121 tests in 1441.927s
[19:13] <kenvandine> OK
[19:13] <kenvandine> sil2100, ^^
[19:14] <sil2100> \o/
[19:15] <sil2100> Ok, need to drop off now, see you in a few hours
[19:15] <kenvandine> sil2100, should i publish that?
[19:15] <sil2100> kenvandine: hm, not sure if the rootfs for 240 already finished
[19:15] <imgbot> [19:15] <sil2100> kenvandine: maybe wait a few and then publish ;)
[19:15] <kenvandine> sil2100, a "few"
[19:15] <robru> kenvandine: rtm 11 doesn't need qa?
[19:15] <kenvandine> how long is that?
[19:16] <kenvandine> robru, no... autopilot only
[19:16] <kenvandine> fixes the smoke tests
[19:16] <robru> kenvandine: cool
[19:16] <sil2100> robru: no, it's just an autopilot change, but kenvandine will publish it if anything
[19:16] <robru> sil2100: k
[19:16] <sil2100> kenvandine: maybe in like 30 mins or so?
[19:16] <kenvandine> sure
[19:16] <sil2100> Thanks guys ;)
[19:17] <kenvandine> sil2100, how can i tell if it's safe?
[19:17] <kenvandine> sil2100, have a good one!
[19:17] <sil2100> kenvandine: hmm... there's a way of checking if the rootfs built but I never remember the links for that ;p
[19:17] <sil2100> See you in a bit o/
[19:22] <ToyKeeper> D'oh, too late.
[19:24] <ToyKeeper> robru, boiko: I can't test silo rtm-015.  The plan is to use 240 as the candidate and take rtm-015 a little slower.
[19:25] <ToyKeeper> It kinda requires specific test lab hardware and 4G, neither of which is available on this continent.
[19:25] <robru> ToyKeeper: hmmm
[19:26] <robru> ToyKeeper: ok well do what you can. if you can only test 240 then so be it. when the europeans wake up they can test 241 then.
[19:58] <boiko> ToyKeeper: so, bug 1421177 is marked as duplicate of another bug by john-mcaleely
[19:59] <boiko> john-mcaleely: can you confirm it is really just a duplicate?
[20:00] <john-mcaleely> boiko, looking
[20:02] <john-mcaleely> boiko, I went on the basis of the commenst in #18 & 19 on that bug
[20:02] <john-mcaleely> it seems that several bugs have poor repros (we lack the equipment), and an engineering call that they may have related fixes
[20:03] <boiko> john-mcaleely: the bug description is very confusing, but re-reading it I think it is correct, unless the reporter says it is not
[20:03] <john-mcaleely> boiko, so my biggest concern would be regressions, rather than confirming those branches fix things
[20:04] <john-mcaleely> boiko, we will not hear from the reporter - they were onsite for one day, and will not go back
[20:04] <boiko> john-mcaleely: so, the branch really fixes 1416292
[20:05] <john-mcaleely> boiko, again, we've never well reproduced that, so it's a judgement call, I think
[20:05] <boiko> john-mcaleely: the chances of regressions are very low
[20:05] <imgbot> [20:05] <imgbot> [20:05] <john-mcaleely> boiko, then I prefer to say we tried to fix it, and did make an improvement
[20:05] <boiko> john-mcaleely: and as I said before, 1416292 is really fixed
[20:05] <john-mcaleely> and therefore land '15
[20:05] <john-mcaleely> excellent
[20:06] <boiko> john-mcaleely: also, with the stuff that already landed on silo 11,  call accepting/hanging up handling was improved a lot
[20:06] <john-mcaleely> boiko, sounds good
[20:07] <boiko> ToyKeeper: so, I think testing the other bugs is enough in this case
[20:08] <john-mcaleely> I think that is the best we can do
[20:08] <boiko> ToyKeeper: also, 1422401 was partially fixed with a fix in ofono that was landed on silo 11, so if you try to reproduce the problem without silo 15, you might not succeed, the telephony-service side of the fix just cover extra failure possibilities
[20:09]  * john-mcaleely eod
[20:18] <robru> ToyKeeper: well there's that ^
[20:31] <ToyKeeper> Hmm, silo rtm-11 didn't actually land in image 240 though, no?
[20:31] <ToyKeeper> It was approved after 240 started building.
[20:31] <kenvandine> ToyKeeper, no it didn't
[20:32] <kenvandine> ToyKeeper, sil2100 wanted it to go in 241
[20:32] <ToyKeeper> Okay.  I'll try to avoid telephony tests on 240, since they'll be obsoleted by 241 anyway.
[20:33] <kenvandine> telephony?  rtm 11 was settings autopilot fixes
[20:33] <ToyKeeper> Okay, looks like there were two different silo 11s then.  :)
[20:33] <kenvandine> ah :)
[20:33] <kenvandine> rtm 11 with settings fixes the smoke test failures
[20:33] <kenvandine> autopilot test changes only
[20:33] <ToyKeeper> Regardless, image 241 should have some new telephony fixes.
[20:34] <kenvandine> ToyKeeper, so then the previous silo 11 should be in 240
[20:44] <boiko> ToyKeeper: flashing 240 here, I can tell if the fixes are there in a minute
[20:44] <ToyKeeper> boiko: I just had two silo 11s mixed up; wasn't aware there were two.
[20:45] <boiko> ToyKeeper: ah ok :)
[20:48] <plars> popey: so did I hear correctly that calendar is back?
[20:50] <imgbot> [20:50] <imgbot> [21:32] <kgunn> trainguard i can give up vivid silo 13
[21:32] <kgunn> trainguards i can give up vivid silo 13
[21:32] <robru> kgunn: sure
[22:33] <robru> cihelp s-jenkins is having some trouble: https://jenkins.qa.ubuntu.com/job/cu2d-choo-choo-autolanding/146/console seems intermittent, I've had some success with retries, but not always
[22:34] <fginther> robru, looking
[22:34] <robru> fginther: thanks
[22:36] <sil2100> o/
[22:36] <sil2100> Hey, did silo 15 land?
[22:37] <robru> sil2100: no, apparently ToyKeeper isn't equipped to qa it.
[22:37] <sil2100> Oh shit
[22:37] <robru> fginther: http://s-jenkins.ubuntu-ci:8080/job/cu2d-choo-choo-ci/ this is the one where the retry worked. the -autolanding one seems just dead
[22:38] <ToyKeeper> sil2100: Even so, I was asked not to, so people in .eu can do it in the morning.
[22:38] <robru> fginther: same traceback as far as i can tell
[22:38] <fginther> robru, there's an issue with a subset of the builder nodes, trying to track it down
[22:38] <sil2100> ToyKeeper: oh, who asked that?
[22:38] <robru> ToyKeeper: whoa whoa, I didn't ask you not to, I just suggested that .eu people could if you couldn't.
[22:38] <ToyKeeper> sil2100: One of the bugs in 15 can only be tested in the test lab, too.
[22:38] <ToyKeeper> Oh, jibel asked me not to.
[22:38] <sil2100> If that's the overall decision then ok, but now I'm really worried about time
[22:38] <robru> ToyKeeper: oh ok cool ;-)
[22:39] <sil2100> ToyKeeper: ok, then I trust that jibel knows best what resources QA has
[22:39] <sil2100> ToyKeeper: I suppose you could do sanity testing on #240 at least for krillin
[22:40] <ToyKeeper> Already doing that, and then on to regression testing for it...  just not the telephony parts.
[22:40] <sil2100> This way at least we'll know if images aren't completely broken
[22:40] <sil2100> Excellent
[22:41] <sil2100> Ok then, so it means I won't be needed
[22:41] <sil2100> See you tomorrow everyone o/
[23:03] <robru> fginther: ah, it merged now, thanks
[23:06] <fginther> robru, I found a corrupted project that appears to be the culprit. I'm now looking for the same problem on other nodes.
[23:06] <robru> fginther: good work!
[23:06] <fginther> robru, but things should be working for those jobs now