[07:58] <Mirv> thostr_: hi. I'm looking at indicator-network for Qt 5.2 rebuild, but I notice it has a landing plan on line17. is the "normalize indicator startup" planned to be landed before Qt 5.2 landing?
[08:11] <Mirv> popey: I still don't see any updates in the DPR branches, so I assume they haven't been tested. I built them now so that if in addition to qt5-beta2 PPA (and optionally landing-006 PPA) you add also ppa:canonical-qt5-edgers/qt5-beta-proper , you should get qtubuntu and ubuntu-ui-toolkit with Kaleo's branches for testing
[08:40] <popey> Mirv: nice one
[08:51] <didrocks> dbarth_: hey, did you see that all AP tests are failing for online_accounts_ui? http://ci.ubuntu.com/smokeng/trusty/touch/mako/221:20140305:20140304/6988/online_accounts_ui/
[08:52] <Mirv> dbarth_: I'm locking libaccounts-qt + signon-* for Qt 5.2 landing, please say if you need to land something urgently to those before Qt 5.2
[08:52] <didrocks> Mirv: I'll probably land a revert, see ^
[08:54] <Mirv> didrocks: ubuntu-system-settings-online-accounts only? that's not yet in the plan. however signon-ui is, are you planning to revert that too (the whole landing line 4)?
[08:54] <didrocks> Mirv: the whole line 4 yeah
[08:54] <didrocks> if we can confirm it's the issue
[08:54] <Mirv> damn, ok, I'm removing signon-ui from my list for now
[08:55] <didrocks> Mirv: ubuntu-system-settings-online-accounts is part of that landing
[08:55] <didrocks> sil2100: can you try to revert components on line4 and rerun AP test on latest image?
[08:55] <sil2100> didrocks: let me check that on my UITK-testing device - since my list of all AP tests didn't have that component ;/
[08:55]  * didrocks writes his revert script meanwhile
[08:55] <didrocks> sil2100: thanks!
[08:56] <sil2100> didrocks: since I ran all from the testing wiki page, and now I see it is missing ubuntu-system-settings-online-accounts
[08:56] <sil2100> So I'll do some testing
[08:56] <didrocks> sil2100: ah, something to add then :)
[08:56] <Mirv> didrocks: yes, but as said I wasn't yet plannign to land it (reqs ubuntu-system-settings which reqs UITK which is not yet in)
[08:56] <didrocks> Mirv: ah ok ;) the "not yet in the plan" -> thought you didn't see it in line 4 :p
[08:57] <seb128> didrocks, Mirv: one of the webapp landing made the desktop ISO unhappy
[08:57] <seb128> daily failed on
[08:57] <seb128>  webapp-container : Depends: qtdeclarative5-online-accounts-client0.1 (>= 0.3) but it is not installable
[08:57] <seb128> do you know about that?
[08:57] <didrocks> ahah! it's the same landing
[08:57] <didrocks> no, didn't look at that yet
[08:57] <didrocks> thanks seb128, probably will be the same global revert
[08:57] <seb128> thanks
[08:58] <didrocks> seb128: hum, was it a bad timing?
[08:58] <didrocks>   Candidat : 0.3+14.04.20140304-0ubuntu1
[08:58] <didrocks> like still in proposed?
[08:58]  * didrocks tries to dist-upgrade
[08:58] <seb128> that email is from 8:32
[08:58] <didrocks> hum, weird, I can dist-upgrade happily here
[08:59] <ogra_`> well, given the state the package seems to be in you probably dont want to :)
[08:59] <sil2100> hmmm hmmm
[08:59] <ogra_`> apt AI protects you :)
[09:00] <didrocks> ogra_`: ahah :)
[09:00] <didrocks> ogra_`: I don't really use that feature anyway, so if it's broken… :p
[09:00] <sil2100> I wonder what I'm doing wrong, running online_accounts_ui AP tests here just results in an instant success, says Ran 4 tests in 0.069s but nothing really started on the device o_O
[09:00] <didrocks> ogra_`: btw, the spreadsheet autoupdate latest proposed an promoted image now (every 5 minutes)
[09:00] <didrocks> sil2100: urgh, waow :p
[09:00] <didrocks> sil2100: can you try flashing fresh latest image?
[09:00] <ogra_`> didrocks, argh, sorry, i forgot to update it
[09:00] <didrocks> just in case
[09:01] <sil2100> didrocks: will do ;)
[09:01] <didrocks> ogra_`: no worry, that was one more insentive to work quietly on that in the morning :)
[09:02] <sil2100> didrocks: ok, so now I know why the list didn't have online_accounts_ui tests...
[09:02] <sil2100> didrocks: the online_accounts_ui tests have this in setUp() -> if model() != 'Desktop': return
[09:02] <ogra_`> beauty !
[09:03] <didrocks> sil2100: ahah :)
[09:03] <didrocks> hum
[09:03] <didrocks> so
[09:03] <sil2100> And in every test
[09:03] <didrocks> why are they all failing?
[09:03] <sil2100> Maybe they changed it now, I'm using the version before the release ;)
[09:03] <sil2100> Let me reflash to latest
[09:03] <ogra_`> Traceback (most recent call last):
[09:03] <ogra_`>   File "/usr/lib/python2.7/dist-packages/online_accounts_ui/tests/test_online_accounts_ui.py", line 304, in test_create_account_with_form
[09:03] <ogra_`>     page = self.app.select_single('NoAccountsPage')
[09:03] <ogra_`> AttributeError: 'OnlineAccountsUiTests' object has no attribute 'app'
[09:03] <didrocks> sil2100: ah ok
[09:04] <ogra_`> missing autopilot changes ?
[09:04] <seb128> shrug
[09:05] <didrocks> ogra_`: that would sound weird though
[09:05] <seb128> didrocks, you guys try to hide your screwup behind empty messages?!
[09:05] <seb128> http://launchpadlibrarian.net/168350693/webbrowser-app_0.23%2B14.04.20140219-0ubuntu1_0.23%2B14.04.20140304-0ubuntu1.diff.gz
[09:05] <didrocks> seb128: hum?
[09:05] <seb128> no upload log
[09:05] <seb128> but that's the issue
[09:05] <Mirv> FYI locking for Qt 5.2 landing: signon-keyring-extension signon-plugin-oauth2 accounts-qml-module libusermetrics telepathy-ofono address-book-service autopilot-qt indicator-network-prompt libdbusmenu-qt qtorganizer5-eds unity-notifications
[09:05] <seb128> webbrowser-app is main,  qtdeclarative5-online-accounts-client0.1 is not
[09:05] <ogra_`> didrocks, well it seems to be looking for the system-settings app there ...
[09:05] <seb128> didrocks, you guys need to Mir the u-s-s stack, good luck :p
[09:05] <seb128> MIR even
[09:06] <didrocks> seb128: "our" screwup?
[09:06] <seb128> whoever acked the landing
[09:06] <didrocks> seb128: http://bazaar.launchpad.net/~phablet-team/webbrowser-app/trunk/revision/454
[09:06] <seb128> that has packaging changes, somebody acked it without checking if the depends are in main?
[09:06] <didrocks> seb128: this is the rev
[09:06] <didrocks> seb128: yeah, seems so
[09:07] <didrocks> seb128: however, the empty message is due to what upstream did…
[09:07] <didrocks> they touched debian/changelog
[09:07] <seb128> sorry the "your" was to whoever acked the packaging change
[09:07] <didrocks> yeah, but it wasn't intended in an empty message though…
[09:08] <Mirv> FYI locked for Qt 5.2 landing: libaccounts-qt signon unity-scopes-shell ofono-qt qmenumodel
[09:12] <didrocks> robru-sick: can you tell us who did the packaging ack? (and you missed the Main/Universe check…)
[09:14] <didrocks> robru-sick: http://162.213.34.102/job/landing-005-2-publish/31/artifact/packaging_changes_webbrowser-app_0.23+14.04.20140304-0ubuntu1.diff
[09:14] <didrocks> robru-sick: webbrowser-app (in main), depends on qtdeclarative5-online-accounts-client0.1 (universe)
[09:14] <didrocks> robru-sick: that's why the desktop iso is broken
[09:14] <didrocks> dbarth_: FYI, another reason to revert ^
[09:15] <didrocks> as we won't be able to put qtdeclarative5-online-accounts-client0.1 in main, as it depends on ubuntu-system-settings
[09:15] <didrocks> and to get that one in main, good luck, a lot of rdepends
[09:23] <Laney> also
[09:23] <Laney> it's not covered by the touch FFe
[09:24] <Laney> so it shouldn't really have been uploaded in the first place :-)
[09:27] <dbarth_> didrocks: that's a desktop issue,right?
[09:27] <dbarth_> didrocks: ie for the phone image, we're still using universe'y stuff
[09:27] <didrocks> dbarth_: there were 2 pings, one desktop, one phone
[09:28] <didrocks> desktop -> image broken because of the depends
[09:28] <dbarth_> so we could make that integration specific to touch, and drop support on the desktop
[09:28] <didrocks> phone -> all AP tests failing
[09:28] <t1mp> sil2100: was it confirmed yesterday that the failures in UITK tests came from the ~/autopilot?
[09:28] <sil2100> t1mp: yes
[09:28] <dbarth_> didrocks: which ap tests?
[09:28] <t1mp> sil2100: ok, thanks
[09:29] <didrocks> 09:51:10   didrocks | dbarth_: hey, did you see that all AP tests are failing for online_accounts_ui?
[09:29] <t1mp> sil2100: it is a "detail" that is easily overlooked when checking the logs
[09:29] <didrocks>                     | http://ci.ubuntu.com/smokeng/trusty/touch/mako/221:20140305:20140304/6988/online_accounts_ui/
[09:29] <sil2100> t1mp: all tests seemed fine so I published UITK ;)
[09:29] <t1mp> bzoltan: ^
[09:29] <t1mp> sil2100: thanks :)
[09:29] <dbarth_> mardy: see the ap test reports above? ^^
[09:29] <dbarth_> mardy: can you investigate why that suddenly fails?
[09:30] <sil2100> dbarth_: in the previous versions of online_accounts_ui all tests were simply disabled for touch
[09:30] <seb128> dbarth_, you want to get webapps out of desktop?
[09:30] <sil2100> dbarth_: did you guys re-enable them now?
[09:31]  * bzoltan hugs sil2100
[09:31] <dbarth_> seb128: no, just the online account integration
[09:31] <dbarth_> seb128: while we resolve the big universe vs main problem (if ever, i'm not so keen on landing that on an LTS right now)
[09:32] <dbarth_> sil2100: not that I know of, since they were blocked on a mir issue
[09:32] <dbarth_> sil2100, didrocks: feel free to revert for now, and we'll sort this out today
[09:32] <seb128> dbarth_, you can't disable it for desktop and keep it for touch, they are the same source
[09:32] <didrocks> dbarth_: yeah, doing that as we speak, just trying to ensure the AP failures are due to latest landing
[09:33] <didrocks> sil2100: joining?
[09:33] <sil2100> Ah
[09:33] <dbarth_> seb128: using a conditional build
[09:33] <Laney> they are the same build
[09:33] <seb128> dbarth_, you can't, that's the same source
[09:33] <didrocks> dbarth_: it's one source, it's the same
[09:33] <seb128> dbarth_, the build-depends need to be in main
[09:33] <didrocks> anyway, let's revert and sort that
[09:33] <dbarth_> oh the dependency
[09:33] <didrocks> seeing the number of things to revert in one shot (the whole transaction), I need to finish my script
[09:33] <mardy> dbarth_, didrocks: I'll check why the tests fail; I didn't change them recently, though
[09:34] <dbarth_> mardy: it may just be the same mir/ui issue with the helper
[09:34] <popey> Saviq: font size of the header in the dash is smaller, is that a desired change?
[09:34] <Mirv> sil2100: FYI I'll also lock appmenu* for Qt 5.2 landing next
[09:34] <dbarth_> mardy: at least we need to know if there's something suddenly horribly broken on the phone, or if that's the same false positive
[09:35] <dbarth_> mardy: then, we have another kind of horrible problem with the dependencies stretched between main and universe
[09:35] <dbarth_> :/
[09:35] <mardy> dbarth_: no, here it looks like the code is broken: http://ci.ubuntu.com/smokeng/trusty/touch/mako/221:20140305:20140304/6988/online_accounts_ui/855302/
[09:36] <mardy> dbarth_: yes, I read that; I guess we need to #ifdef the code which integrates with OA
[09:36] <dbarth_> mardy: not even, the dependency can't be conditional, it's 0 or 1
[09:36] <popey> Saviq: http://imgur.com/VJhDsby  (left phone is #194, right phone is latest)
[09:37] <dbarth_> mardy: can you check what changed in the python glue?
[09:37] <mardy> dbarth_: I think we need to remove the dependency, and make webbrowser app attempt to talk to OA, and fail gracefully if it's not there
[09:37] <mardy> dbarth_: sure
[09:38] <dbarth_> mardy: ah i see, runtime resolution, better, if you can resolve the underlying build dependency issue
[09:38] <t1mp> sil2100: I think we need to automate removing /home/phablet/autopilot otherwise this problem will come back
[09:38] <dbarth_> mardy: cause i guess that you can't build for main with a universe dependency, so you need to embrak the headers or dbus interface definition somehow
[09:39] <sil2100> t1mp: right, I mentioned this on the Testing wiki, but yeah... even I keep forgetting about that
[09:39] <mardy> dbarth_: the dependency is in the QML code: we can put all the OA stuff behind a Loader element; if the OA module is not installed, the loading will fail (gracefully)
[09:40] <mardy> dbarth_: so we could then remove the dependency from debian/control
[09:40] <Laney> didrocks: can you make sure the FFe is communicated to people doing publishing?
[09:40] <dbarth_> ok
[09:40] <mardy> dbarth_: the OA module is installed on unity8 anyway
[09:40] <Laney> how it doesn't cover everything under train
[09:43] <t1mp> sil2100: can't we simply add rm -rf /home/phablet/autopilot to the script that fetches packages from the ppa before running the tests?
[09:43] <popey> Saviq: related to bug 1276173 ?
[09:43] <cjwatson> didrocks: so are we good to enable ppc64el in citrain now, if I go feed webops the instructions?
[09:44] <cjwatson> namely
[09:44] <cjwatson> ppc64el = lp.processors.getByName(name="ppc64el")
[09:44] <cjwatson> for archive in lp.people["ci-train-ppa-service"].ppas:
[09:44] <cjwatson>     archive.enableRestrictedProcessor(processor=ppc64el)
[09:45] <didrocks> Laney: oh, this was MORE than communicated
[09:45] <didrocks> Laney: as the Main vs Universe checking :/
[09:45] <Laney> heheh
[09:49] <didrocks> cjwatson: yeah, sounds good to me
[09:49] <didrocks> cjwatson: I'll keep on eye on it
[09:51] <Saviq> popey, you mean the header misalignment? yeah, probably
[09:51] <popey> Saviq: no, font size has changed
[09:52] <ogra_`> Saviq, looks like a wanted UITK change from Kaleo
[09:52] <Saviq> popey, yeah, that's what I meant, and yes it was a wanted change
[09:52] <mardy> jibel: hi! I want to add the ubuntu-system-settings-online-accounts autopilot tests as autopkgtest; can you point me at some other package I can use as example?
[09:52] <Saviq> we need to adapt to it
[09:52] <Saviq> although it's weird I'm not seeing it on my phone...
[09:54] <Saviq> ah probably uitk not rebuilt in qt5-beta2
[09:56] <jibel> mardy, any package listed on https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/
[09:57] <Laney> http://packaging.ubuntu.com/html/auto-pkg-test.html
[09:58] <didrocks> mardy: dbarth_: please update your tests procedure to ask to run those tests on the phone and desktop :)
[09:58] <Mirv> sil2100: I'm wondering if I can add a comment about landing after Qt 5.2 to line 6, since I guess it's not related to getting a promoted image done?
[09:58] <Mirv> (similar to line 17 that was already agreed)
[09:58] <jibel> mardy, for autopkgtest with autopilot, I think autopilot-gtk is a good starting point.
[09:58] <jibel> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-autopilot-gtk
[10:00] <Mirv> psivaa: did you have the crasher link to look at?
[10:00] <psivaa> Mirv: ohh i posted that in the ho.. https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/118/artifact/clientlogs/dropping_letters_app/
[10:01] <Mirv> psivaa: ah I guess I didn't see it there
[10:01] <Mirv> thank you
[10:01] <psivaa> Mirv: yw
[10:04] <sil2100> Mirv: line 6, let me see that
[10:04] <sil2100> Mirv: right
[10:04] <sil2100> Mirv: you can add the comment ;)
[10:05] <cjwatson> OK, CI Train is building on ppc46el now
[10:05] <cjwatson> ppc64el, even
[10:05] <Mirv> sil2100: thanks!
[10:06] <cjwatson> Will probably only affect new uploads, not existing ones
[10:06] <tvoss> cjwatson, just completed pass one through your epic click mp :)
[10:06] <tvoss> cjwatson, now coffee and after that pass two
[10:07] <cjwatson> I shall wait in trepidation
[10:08] <cjwatson> grouper builds are still limping along, yes?
[10:10] <ogra_`> yep
[10:12] <didrocks> hum
[10:12] <didrocks> who removed the MPs from landing 4?
[10:13] <didrocks> whoever did it, can you restore please?
[10:13] <didrocks> thanks cjwatson :)
[10:23] <dbarth_> didrocks: +1, and adding an autopackage test as well
[10:23] <didrocks> thx
[10:33] <Mirv> psivaa: I filed bug #1288168 but seems fairly identical to the earlier #1284581
[10:33] <sil2100> uuuuu
[10:33] <Mirv> ie somewhere deep inside v8
[10:38] <psivaa> Mirv: ok, thanks. I dint see v8f8  hence thought it was different
[10:41] <seb128> didrocks, is that known that the gdoc doesn't pick new status in case of retries?
[10:41] <didrocks> seb128: you need to rerun "build" with "watch only"
[10:41] <seb128> didrocks, silo 13 failed yesterday due to a merge conflict, that got resolved and I clicked build again, which failed for another reason, but it's still listing "merge conflict"
[10:41] <didrocks> seb128: hum, shouldn't be the case
[10:42] <didrocks> can't look before I finish the revert though
[10:42] <seb128> (the another reason is an archive issue which made one of the source ftbfs)
[10:42] <didrocks> if anyone else can from the LT can look ^
[10:42] <seb128> didrocks, do you want me to keep it in state for you?
[10:42] <didrocks> seb128: that would be great, or if anyone can help
[10:42] <seb128> k
[10:42] <seb128> no hurry for the landing
[10:42] <seb128> didrocks, thanks
[10:48] <sil2100> didrocks: I have to modify the terminal-app test a bit, but I have a branch ready
[11:25] <sil2100> popey: who do you think could review my terminal-app AP test fix branch?
[11:26] <didrocks> ok, reverted and reverter written
[11:30] <popey> sil2100: balloons?
[11:30] <didrocks> seb128: what was the issue? seems that even latest build failed to build, see http://162.213.34.102/job/landing-013-1-build/20/console
[11:30] <didrocks> 2014-03-05 09:12:48,740 INFO Some of the packages failed to build: unity-control-center (14.04.3+14.04.20140305-0ubuntu1)
[11:30] <didrocks> due to:
[11:30] <seb128> didrocks, archive issues
[11:31] <didrocks> 2014-03-05 08:57:36,593 ERROR i386: Build i386 build of unity-control-center 14.04.3+14.04.20140305-0ubuntu1 in ubuntu trusty RELEASE (https://launchpad.net/~ci-train-ppa-service/+archive/landing-013/+build/5660949) failed because of Failed to build
[11:31] <didrocks> ok
[11:31] <didrocks> so you rerun it?
[11:31] <seb128> no
[11:31] <didrocks> I don't see a rerun with "watch only"
[11:31] <seb128> - it failed first yesterday due to a merge conflict
[11:31] <didrocks> yep
[11:31] <seb128> - I ran it again this morning
[11:31] <seb128> -> it hit the archive issue
[11:31] <seb128> the gdoc still claims "merge conflict" in its status though
[11:31] <didrocks> ah indeed, the spreasheet is still showing up merge conflict
[11:31] <seb128> I let it in this state for you to debug the buggy status
[11:31]  * didrocks wonders if the spreadsheet is again in hell…
[11:33] <seb128> didrocks, is "watch_only" doing an actual rebuild? the description suggests it doesn't?
[11:34] <didrocks> An attempt to set a spreadsheet value has failed due to the spreadsheet's data validation settings. (line 53, file "silos")
[11:34] <didrocks> seb128: no, it's just scanning again
[11:34] <didrocks>       pendingUIDCell.setValue(uid);
[11:34] <didrocks> it doesn't want to free it
[11:34] <seb128> didrocks, right, I need a build retry in my case though ;-)
[11:35] <seb128> didrocks, silo is "thinking" ;-)
[11:35] <didrocks> seb128: yeah, so for now, the only way is to retry in the ppa (you should have access, let me fix that)
[11:35] <seb128> but the status didn't get cleared
[11:35] <didrocks> after debugging
[11:36] <didrocks> and then, you rerun "watch ppa"
[11:36] <seb128> didrocks, right, I would after retried, as said I just pinged because of the status
[11:36] <seb128> k
[11:36] <didrocks> nice, pendingUIDCell.getValue() isn't possible even
[11:36] <didrocks> wth?
[11:42] <sil2100> didrocks: anyway, here is the branch - I'll try to poke someone to get it reviewed and landed: https://code.launchpad.net/~sil2100/ubuntu-terminal-app/autopilot_fix_thumbspacing_0/+merge/209427
[11:44] <didrocks> sil2100: thanks
[11:44] <didrocks> I don't understand, it's like if someone tried to put data validation everywhere
[11:44] <didrocks> but I don't find them in the spreadsheet
[11:47] <didrocks> waow, the first get pass
[11:47] <didrocks> I don't change the value
[11:47] <didrocks> the second fails…
[11:48] <didrocks> oh, I found it
[11:48] <didrocks> it's stupid, it's clearly not due to that…
[11:54] <didrocks> seb128: ok, better now :)
[11:54] <didrocks> nice, you pass reference to GAS and it's using then absolute paths
[11:54] <didrocks> so of course, when you change the reference…
[11:55] <didrocks> seb128: and you can rebuild now
[11:58]  * didrocks restores also what people remove in the spreadsheet
[11:58] <didrocks> sil2100: can you restore the MPs list please btw on the first landed?
[11:58] <didrocks> sil2100: it seems they were removed and you had the focus on it :p
[12:11] <didrocks> bzoltan: hey, so now your turn ;)
[12:12] <didrocks> bzoltan: did you run all AP tests with latest sdk upload?
[12:12] <Mirv> sil2100: could you perhaps decomission landing-007 since otherwise Qt prepare-silo would complain that content-hub is already in a silo?
[12:16] <bzoltan> didrocks: yes, all the MRs were tested against the AP test suite, like before
[12:17] <bzoltan> didrocks: but yesterday I left the office with the status that it is not landing because of failing tests
[12:17] <didrocks> bzoltan: ah, do you know who landed it?
[12:17] <bzoltan> didrocks: no
[12:17] <didrocks> bzoltan: can you gather that information?
[12:17] <didrocks> bzoltan: terminal-app fails due to fontsize
[12:17] <didrocks> (only the tests, so we move on and fix the test)
[12:17] <didrocks> but would have been great to have that coordinated
[12:19] <bzoltan> didrocks: t1mp told me that sil2100 helped yesterday to verify
[12:19] <bzoltan> didrocks: and robru-sick told me to merge and clean up the Silo
[12:20] <didrocks> bzoltan: we just counter-sign, I'm interested in who tested on your side :)
[12:21] <Mirv> sil2100: or is it enough btw to add the offending merge mention from the spreadsheet?
[12:25] <didrocks> bzoltan: still here?
[12:26] <bzoltan> didrocks: yes, on Mumble
[12:26] <didrocks> ok, keep me posted
[12:26] <bzoltan> didrocks: me and the top approver of the MRs
[12:27] <didrocks> bzoltan: ok, can you ensure that you look closely at the results? Do you know why the terminal one failed? (not trying to point fingers, but trying to understand what/how we can improve the process)
[12:27] <bzoltan> didrocks: and yesterday t1mp has run an other round with the MRs from the MP
[12:31] <t1mp> sil2100: you landed yesterday's UITK right?
[12:34] <bzoltan> didrocks: this is the logs from the last tests -> http://paste.ubuntu.com/7034340/ I knew yesterday that we have issues, so I expected to resolve the problem and do the landing today. Today I have heard that the failures were false and the MP landed ...
[12:34] <didrocks> bzoltan: 17:36:41.672 ERROR testresult:43 - FAIL: ubuntu_terminal_app.tests.test_terminal.TestMainWindow.test_font_size_changes(with touch)
[12:35] <didrocks> 17:36:41.676 ERROR testresult:43 - traceback: {{{
[12:35] <didrocks> Traceback (most recent call last):
[12:35] <didrocks>   File "/home/phablet/autopilot/ubuntu_terminal_app/tests/test_terminal.py", line 175, in test_font_size_changes
[12:35] <didrocks>     self.assertThat(font_size, Equals(32))
[12:35] <didrocks>   File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 406, in assertThat
[12:35] <didrocks>     raise mismatch_error
[12:35] <didrocks> MismatchError: 32 != 14
[12:35] <didrocks> so you catched it
[12:35] <didrocks> not sure who turned as the lander the "tested" to yes?
[12:37] <seb128> didrocks, thanks
[12:41] <didrocks> t1mp: he did, why?
[12:41] <t1mp> didrocks: I was trying to help you figure out who landed it
[12:41] <t1mp> 13:17:19 < didrocks> bzoltan: ah, do you know who landed it?
[12:42] <t1mp> but you figured it out already
[12:42] <didrocks> t1mp: right, my question is more who tested and acked it on the upstream side?
[12:42] <didrocks> t1mp: we are just "publishing", we are not the lander
[12:42] <ralsina_> sil2100, Mirv, didrocks: can I get a silo for row #59 please?
[12:47] <Mirv> ralsina_: could that wait until after Qt 5.2? I'm just about to land ubuntu-download-manager there
[12:47] <ralsina_> Mirv: sure thing
[12:48] <Mirv> ralsina_: ok, thanks!
[12:50] <Mirv> didrocks: now that the signon-ui is reverted, does it need a Qt 5.2 branch which does the actual revert too (+ rebuild), or is the plan to get signon-ui again in before Qt 5.2?
[12:50] <didrocks> Mirv: check maybe directly with upstreaM?
[12:52] <Mirv> dbarth_: are you planning to land the signon-ui & co again before Qt 5.2, or can I lock signon-ui now for Qt 5.2 landing?
[12:55] <Mirv> didrocks: can you help with what sil2100 didn't respond to, ie. landing line 6 (silo landing-007) that has among else content-hub that'd be now postponed to after Qt 5.2 and clashed with Qt 5.2 landing? I don't want to do any freeing on my own.
[12:57] <didrocks> Mirv: I guress it's the same than the other one: please check directly with the landers I guess
[12:57] <didrocks> Mirv: to ensure they agree on the best plan
[12:57] <didrocks> and not free up that silo without having them aware of this
[12:58] <Mirv> didrocks: right, sil2100 said it was ok but I'll check with bfiller then too first. he should be online soon.
[12:59] <didrocks> yep
[12:59] <dbarth_> Mirv: i think you can lock it
[13:00] <dbarth_> mardy: right? ^^
[13:00] <dbarth_> Mirv: but be aware of that webapps + oa landing that had dependency issues (between main / universe), so this should have been reverted by now, and that contained signon-ui as well
[13:01] <didrocks> Mirv: you need to include the revert in your work, of course
[13:02] <didrocks> sil2100: still not around? :/
[13:02] <Mirv> dbarth_: yes, ok thanks!
[13:03] <Mirv> didrocks: indeed, I did that at https://code.launchpad.net/~timo-jyrinki/signon-ui/rebuild_against_qt521_and_sync_with_archive
[13:04] <didrocks> thanks Mirv
[13:10] <t1mp> is there a way for me to trigger jenkins CI for this MR? https://code.launchpad.net/~mzanetti/ubuntu-ui-toolkit/drop-bottombarvisibilitycommunicator/+merge/209446
[13:10] <t1mp> as I understood, jenkins does not run for MRs proposed by people outside the SDK team?
[13:11] <t1mp> or is that for people who are not canonical?
[13:17] <sil2100> didrocks: was on lunch, what's up?
[13:17]  * sil2100 backlogs
[13:18] <cjohnston> t1mp: its already running
[13:18] <cjohnston> it runs automatically
[13:18] <cjohnston> for Canonical
[13:21] <t1mp> cjohnston: ok, thanks
[13:21] <sil2100> Mirv: I guess check with Bill first, but I don't see a problem with that
[13:23] <mardy> dbarth_, Mirv: yes, there are no planned releases for those packages
[13:24] <didrocks> mardy: they are reverted, just ensure you know that
[13:24] <mardy> dbarth_, Mirv: no, wait...
[13:24] <mardy> didrocks: I just noticed :-)
[13:25] <mardy> Mirv: depends on when Qt 5.2 is going to land :-)
[13:25] <didrocks> dbarth_ knows about it
[13:25] <didrocks> sil2100: and about restoring line 4 for MPs?
[13:26] <didrocks> bzoltan: any news on who ran the tests?
[13:26] <Mirv> mardy: that depends on a couple of things, but the general idea was to land Qt 5.2 as soon as possible with only fixes going in before it that could help promote an image before Qt 5.2 landing
[13:26] <bzoltan> didrocks: I told you, t1mp and me + the top approver of each MR as a requirement for the MP inclusion
[13:27] <mardy> Mirv: OK, makes sense then
[13:27] <Mirv> mardy: I could finish Qt 5.2 landing theoretically even tomorrow, but indeed the landing depends on what to do with a couple of bugs and generally if quality has been assessed enough
[13:27] <didrocks> bzoltan: ok, seems multiple level of failures, how do you think we would have avoided that?
[13:27] <didrocks> what can we improve?
[13:28] <bzoltan> didrocks: 1. not to land anything before the lander says so 2. more frequent landing of the UITK with only single MRs
[13:28] <didrocks> sil2100: did you land before anyone gave you a +1? ^
[13:29] <didrocks> as it seems that's what bzoltan is telling
[13:29] <bzoltan> didrocks: the sheet was bumpy yesterday ... the values changed back and forth ... that did not help ...I turned once the tested to green and I turned it back to red ... it might got mixed up
[13:30] <bzoltan> didrocks: I left the office yesterday with knowing that the tests fail and I tasked t1mp to re run the tests at a later hour and show me the results in the morning
[13:30] <sil2100> bzoltan: you said that it's ready to land, so I landed it
[13:30] <sil2100> Let me see the logs
[13:30] <didrocks> sil2100: thanks for restoring line 4 btw :)
[13:30] <bzoltan> sil2100: ready to land ... if the tests are good :)
[13:31] <sil2100> 15:21 < bzoltan1> sil2100: Mirv: the UITK is built and tested -> http://162.213.34.102/job/landing-004-1-build/46/console
[13:31] <bzoltan> sil2100:  I was not sure yesterday that the failures are caused by the MP or by some other magic ... all the MRs are device tested before I enter to the landing proposal.... and
[13:32] <didrocks> bzoltan: that's seems like a +1 for me as well ^
[13:32] <bzoltan> sil2100:  yes... and after that you told me that the tests fail
[13:32] <sil2100> I didn't get anything else since that time, I was double-checking myself if tests were ok, I might have missed terminal-app though, although I remember running it
[13:33] <sil2100> bzoltan: well, the failures in UITK test suite were a non-issue, I told t1mp about that
[13:33] <bzoltan> sil2100: I know... but I left the office before that
[13:33] <sil2100> Ah, ACK
[13:34] <bzoltan> sil2100: (2014-03-04 20:32:40) t1mp: sil2100: for me the AP tests failed also after merging all the MRs that we are trying to land http://paste.ubuntu.com/7034340/
[13:35] <bzoltan> sil2100: didrocks: OK.. I see what has happened ... there was an AP issue what caused failures, after solving that one the tests were not re-run
[13:35] <didrocks> cjwatson: I won't be able to come in http://summit.ubuntu.com/uds-1403/meeting/22158/core-1403-qt5-versioning/ as it's not in my track and I need to host the video for one of the clien troom
[13:36] <didrocks> bzoltan: ok, just ensure the communication is smoother in the future :)
[13:37] <bzoltan> didrocks: My take away is that one green test is not a green test... two green tests are green tests
[13:37] <didrocks> bzoltan: yeah, not sure we can double check all the time though. and that double checking even failed on that case
[13:37] <bzoltan> didrocks: and after fixing a red tests ... it is better to wait for a green test and not to _assume_ :D that we did not overlook a hiding failure.
[13:39] <bzoltan> didrocks: errr.. how to say  ... just because you put back the cheese to the fridge it does not mean that nobody farted.
[13:39] <sil2100> Miscommunication and probably a test missed from double-checking ;) Good thing it's nothing serious
[13:40] <cjwatson> didrocks: OK, thanks.  Can anyone else knowledgeable from the landing team make it?
[13:40] <sil2100> bzoltan: just to make sure - you guys did run the terminal-app tests on the uitk from the silo?
[13:40] <didrocks> cjwatson: Mirv… or just move the session to my track
[13:40] <cjwatson> didrocks: I have no problem with that, it's only on core because Steve asked me to schedule it
[13:40] <didrocks> cjwatson: ok, let's see with him if we can move it
[13:41] <bzoltan> sil2100: http://paste.ubuntu.com/7034340/ .. it has that terminal test failure ... we simple overlooked it
[13:42] <sil2100> hooo, ok, let's make sure we don't do that next time ;D
[13:43] <sil2100> On both sides!
[14:02] <bregma> hey sil2100 do me a favour an allocate a silo for line 28 SVP?
[14:03] <seb128> sil2100, bregma: wait a sec
[14:03] <sil2100> hmm?
[14:03] <bregma> I am nothing if not patient
[14:03] <didrocks> bregma: can you give a better description?
[14:03] <bregma> sure
[14:04] <seb128> bregma, I think you can drop https://code.launchpad.net/~robert-ancell/unity/ubuntu-session/+merge/207346 from it, we made ubuntu-desktop brings ubuntu-session
[14:04] <seb128> bregma, that was a transitional but we had water under the bridge while it was waiting :p
[14:05] <bregma> seb128, OK, I was asked to delay it until after the transition... it;s also OK to cancel MPs so we don't have to go through all the tests
[14:06] <seb128> bregma, oh, is that a "making double sure the session is installed on upgrade"?
[14:06] <seb128> bregma, well, I've no strong opinion, it's a circular depends but that should be fine for the LTS
[14:08] <sil2100> Just give me a sign when I can assign ;p
[14:09] <seb128> sil2100, up to bregma, I just wanted to make that comment
[14:09] <sil2100> bregma: should I? ;)
[14:09] <seb128> that mp doesn't seem strictly necessary but it might help a few users who uninstalled ubuntu-desktop
[14:09] <seb128> we can still drop it later if that turns out to be an issue
[14:11] <bregma> I dropped the MP from this batch, enhanced the description, sil2100 I thik it's ready for assignment now
[14:12] <sil2100> Ossum
[14:14] <sil2100> bregma: assigned!
[14:14] <bregma> excellent
[14:26] <cgoldberg> didrocks, ping.. I'm following up on Autopilot.  What do I need to do to get it landed?  it's been merged already back to trunk
[14:26] <didrocks> cgoldberg: yeah, you need to have the bug fixed and ensure this time you don't regress anything
[14:27] <cgoldberg> didrocks, we can retest unity8... but thomi already confirmed it wasn't a regression afaik.. so I don't know of any fix to MP
[14:27] <didrocks> cgoldberg: did you look at my answer?
[14:28] <didrocks> cgoldberg: thomi talked about another test
[14:28] <didrocks> not the one that Saviq pointed out
[14:28] <didrocks> and you also have a bug report which was linked with all infos (that didn't get any comment)
[14:28] <mardy> jibel: are autopkgtests always run as root?
[14:30] <cgoldberg> didrocks, ok.. this one?  https://bugs.launchpad.net/autopilot-qt/+bug/1287727
[14:30] <didrocks> cgoldberg: yeah
[14:33] <elopio> cgoldberg, didrocks, fwiw, on the run thomi and I were looking at, that test didn't fail:
[14:33] <elopio> http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/57/label=mako-07/testReport/unity8.shell.tests.test_notifications/InteractiveNotificationBase/
[14:34] <didrocks> elopio: seems that we were able to reproduce reliably with Saviq though (as stated on the bug report and mail)
[14:34] <didrocks> so worth digging I guess :)
[14:35] <Saviq> elopio, cgoldberg, I had 100% success rate with it with previous (and the currently new - reverted) ap, and 100% failure rate on the one that was reverted
[14:38] <elopio> didrocks, Saviq: I agree we need to investigate. Just saying that it was indeed tested by thomi. As it passed, we didn't check further on it.
[14:38] <didrocks> elopio: ok :)
[14:38] <didrocks> would have been worth commenting on the bug report to share the infos :)
[14:43] <Mirv> pmcgowan: one more bug, bfiller did assign this yesterday but the armhf test failure should be sorted out: https://bugs.launchpad.net/telephony-service/+bug/1287619
[14:48] <boiko> Mirv: I'm on it already, no idea what is causing it yet though :/
[14:49] <kgunn> Mirv: i basically agree in spirit Qt5.2 should go first...however, i'd like some grace from didrocks to get a silo for mir asap after that (regardless of Qt5.2 landing results)
[14:49] <kgunn> see mail i just sent for more
[14:49] <didrocks> kgunn: did you sync with tvoss?
[14:49] <didrocks> I think we can't delay anymore, so if we want Mir before 5.2 it's now that we should assign a silo
[14:50] <didrocks> sil2100: maybe you know? ^
[14:50] <Mirv> boiko: thanks!
[14:50] <kgunn> didrocks: i didn't talk to tvoss but thostr_ said antti tested tvoss's silo...so i was hoping it'd be clear soon
[14:50] <kgunn> (the lock on platform-api that is)
[14:51] <sil2100> didrocks, kgunn: it's hard to say, I would say it's close to being released
[14:51] <davmor2> popey: I can't reproduce your issue with the web browser.
[14:51] <tvoss> kgunn, on it, just found a way to finally make the symbols files maintainable
[14:52] <didrocks> sil2100: tvoss: can you keep kgunn posted? I think he should have a silo in the next couple of hours so that we don't delay the Qt landing
[14:52] <didrocks> kgunn: a day should be fine for you to land Mir?
[14:52] <kgunn> didrocks: yep...if i can get a silo by my lunch...should be fine
[14:52] <didrocks> kgunn: not client abi breakage, right? only server?
[14:52] <davmor2> popey: ah now I can
[14:52]  * kgunn secretly knows there will be something else
[14:53] <kgunn> didrocks: right just the server
[14:53] <didrocks> ok ;)
[14:53] <kgunn> which does make life easier :)
[14:53] <didrocks> yeah, no need to have someone uploading to the ppa xorg and so on
[14:54] <davmor2> popey: I was using links from the home page, that seems to work if I go to google and search cats and then click on a link it doesn't.  How bazaar
[14:54] <kgunn> didrocks: curious...so that papi lock is just a rebuild...wonder, could you consider/create a mechanism to note that and allow subsequent land attempts to utilize ?
[14:55] <kgunn> at least for future landings
[14:57] <sil2100> It's a bit complicated from the branch-merge-stuff side
[14:57] <didrocks> kgunn: the question if you don't take a lock is "when do you know you can test?" (and your work won't be trashed if you test a version and someone else land another element)
[14:59] <kgunn> didrocks: that's why it would be awesome...no locking...just a conditional in the sheet to say "retest, you cannot land, someone changed a project you have before you landed"
[14:59] <kgunn> and that would make the whole ord
[14:59] <kgunn> org
[14:59] <kgunn> actually look
[14:59] <didrocks> kgunn: this is the airline
[14:59] <didrocks> :)
[14:59] <kgunn> what we have today is everyone just standing around with thumb-up-rear
[14:59] <didrocks> remember the citrain is a stop gap measure
[14:59] <kgunn> or even worse....just more luggage piling up on platform
[15:00] <didrocks> kgunn: well, this is completely designed in what you wanted. It seems that people wanted an intermediate solution in between, I just was asked to implement it
[15:01] <kgunn> ack...i'm just a customer providing feedback
[15:01] <didrocks> so yeah, the global idea of what you are asking is in the finale vision
[15:01] <didrocks> now, the question to when it will be delivered is not up to me or my team as we don't implement it
[15:04] <didrocks> kgunn: until up, I suggest that we are more aggressive on purging silos, as it's just to deliver and not to get a long-time living lock
[15:04] <didrocks> (that's what I proposed on Monday but tvoss told he would be done by end of yesterday)
[15:06] <kgunn> didrocks: so i was originally in limbo due to android4.4.2+unity8+APfmwk...and it was all about getting back to green
[15:06] <kgunn> i'm not trying to be a smart alec...but
[15:07] <sil2100> I think we should be able to release today
[15:07] <sil2100> tvoss: ^ ?
[15:07] <kgunn> we are landing again right ?
[15:07] <kgunn> (but we're still finding our way back to green)
[15:07] <didrocks> kgunn: right, and notice that we help resuming even if we aren't totally green
[15:07] <kgunn> i'm really asking...
[15:07] <didrocks> it's a mitigation
[15:07] <kgunn> got it
[15:07] <didrocks> and that is asking us *a lot* of more work
[15:07] <didrocks> and hours
[15:07] <didrocks> (crossing 13h a day due to that)
[15:08] <didrocks> so it's more a favor and help than anything
[15:08] <didrocks> (but seems effort are not really recognized and people prefer to go to the "it's not working" path)
[15:09]  * didrocks wonders if next time, we should just say "ok, let's not try to help"
[15:09] <didrocks> but again, it's showing up that everytime we land something not fully ready, we pay the price
[15:09] <sil2100> balloons: hi, are you around?
[15:09] <didrocks> and we should have everyone on the direction to get that fixed asap rather than everyone just focusing on their own little silos
[15:10] <didrocks> s/silos/island/
[15:10] <didrocks> (or people will think I'm speaking of CI train)
[15:10] <balloons> sil2100, howdy
[15:11] <sil2100> balloons: \o/ can I ask you for a review of a terminal-app test failure workaround?
[15:11] <sil2100> balloons: https://code.launchpad.net/~sil2100/ubuntu-terminal-app/autopilot_fix_thumbspacing_0/+merge/209427
[15:11] <tvoss> didrocks, I think it does not scale that everyone looks at everything and I think our landing process should help in decoupling instead. Or am I missing something?
[15:12] <didrocks> tvoss: well, it's clearly what the airline is for
[15:12] <didrocks> tvoss: but we don't have it yet
[15:12] <tvoss> didrocks, got an eta for the airline?
[15:12] <balloons> sil2100, sure, I'll have a look
[15:12] <didrocks> 16:01:13   didrocks | so yeah, the global idea of what you are asking is in the finale vision
[15:12] <didrocks> 16:01:26   didrocks | now, the question to when it will be delivered is not up to me or my team as we don't implement it
[15:12] <didrocks> tvoss: ^
[15:13] <tvoss> didrocks, how much effort would it be to fix the ci train. feels weird to wait for something without an eta
[15:13] <didrocks> tvoss: "fix ci train"?
[15:13] <tvoss> not saying your team is responsible, but trying to understand the scope here
[15:14] <didrocks> tvoss: ci train is a stop gap measure, it can't enable having silos
[15:14] <didrocks> tvoss: so we just all have to work in intelligence until we have the airline and not blocking silos for multiple days if someone else is waiting
[15:15] <tvoss> didrocks, sil2100 I'm tired of this, just tear down the silo and let kgunn step ahead. I will not rush this stuff again, and spend days cleaning up
[15:16] <didrocks> sil2100: can you do?
[15:17] <sil2100> Ah... hm... ok
[15:17] <didrocks> thanks sil2100
[15:17] <sil2100> Freeing the silo
[15:17] <sil2100> np ;)
[15:18] <didrocks> then kgunn can start working :)
[15:18] <sil2100> Too bad, tvoss was so close..!
[15:18] <sil2100> The symbols files suddenly started looking sane, looking awesome
[15:28] <sil2100> balloons: thank you!
[15:33] <sil2100> didrocks, kgunn: silo cleaned out
[15:33] <didrocks> kgunn: and silo 3 for you
[15:33] <sil2100> Should I assign a silo for Mir?
[15:33] <didrocks> too slow dude!
[15:33] <sil2100> Ah, done already ;)
[15:33] <didrocks> yeah, I probably looked in between :)
[15:33] <kgunn> ack
[15:37] <didrocks> kgunn: seems you do have some merge conflicts
[15:38] <sil2100> HOW DARE HE
[15:38] <sil2100> !
[15:38] <kgunn> yes...otp
[15:40] <didrocks> ogra: building a new image now, anything against?
[15:40] <ogra> no, go ahead
[15:40] <didrocks> [15:40] <didrocks> or whatever your tag is :p
[15:41] <ogra> heh
[15:41] <ogra> close
[15:51] <balloons> sil2100, your branch for terminal does seem to fix the issue, but I left a comment on how it works
[15:53] <popey> \o/
[15:54] <sil2100> balloons: looking
[15:55] <sil2100> balloons: ah, the redragging was always there, thought it was what they had in mind ;)
[15:56] <balloons> sil2100, yea I was thinking that might be the case, but I wonder if it's intended
[15:56] <balloons> I should look closer at the testcase, heh
[15:56] <sil2100> balloons: I don't know, maybe it's not - it would certainly decrease the time needed for the test to execute
[15:57] <sil2100> balloons: so, hm, let's maybe change it as you say
[15:58] <balloons> sil2100, yea the test simply sets to min / max, then 3 random sizes.
[16:10] <sil2100> ah, almost forgot to push
[16:10] <sil2100> balloons: pushed modification
[16:12] <balloons> testing
[16:13] <balloons> sil2100, looks good ;-)
[16:13] <sil2100> \o/ Can we get it released somehow ;p?
[16:13] <sil2100> Ah, I guess it's enough if it's in trunk merged, right?
[16:13] <balloons> we'll have to do a release, but yes we can
[16:14] <balloons> I'll approve and start the process
[16:14] <sil2100> As phablet-click-test-setup fetches AP from bzr, right?
[16:14] <sil2100> Ok :)
[16:14] <sil2100> Thanks!
[16:14] <balloons> it fetches the version released, not trunk :-)
[16:27] <didrocks> slangasek: I heard you wanted to discuss as vUDS core-dev landings process, maybe we should get that in https://blueprints.launchpad.net/ubuntu/+spec/client-1403-landing-process-touch?
[16:27] <didrocks> btw, I'll need someone to approve it for vUDS
[16:27] <didrocks> seb128: ? ^
[16:27] <seb128> didrocks, done
[16:27] <didrocks> thanks :)
[16:27] <seb128> yw
[16:32] <davmor2> popey: what devices do you have?
[16:33] <popey> davmor2: mako/flo
[16:33] <davmor2> popey: on the flo can you open the terminal and let me know where the text input line is
[16:34] <popey> ah, i know the answer to this
[16:34] <popey> its above the header
[16:34] <popey> its on my list of bugs to file
[16:34] <popey> feel free to beat me to it
[16:34] <davmor2> popey: unless you rotate it then the header is filled in correctlty
[16:35] <popey> rotate, rotate back it fixes it, yes
[16:36] <davmor2> popey: I'll file it in a second only seems to effect flo
[16:36] <davmor2> pmcgowan: do you have an n10?
[16:36] <popey> davmor2: thanks, ping me and I'll confirm
[16:37]  * sil2100 just got some SPAM from pitti's e-mail
[16:38] <pmcgowan> davmor2, I do
[16:40] <davmor2> pmcgowan: can you open the terminal, type in sudo system-image-cli -i, and then rotate the device and confirm that most of the text output is now missing
[16:41] <davmor2> pmcgowan: only happen on the terminal in sidestage so I'm not sure if it is the terminal or mir/sidestage at fault
[16:41] <pmcgowan> davmor2, do I need a certain version? my N10 is loaded as of last week I think
[16:41] <pmcgowan> davmor2, oh hang it, I have qt5.2 here would need to reflash
[16:42] <davmor2> pmcgowan: meh no worries
[16:44] <slangasek> didrocks: it seems we should have a discussion about core-dev and landings, yes - I think it probably warrants a separate session, which I'll add to the schedule.  As for your blueprint, summit doesn't let me schedule things from other tracks. ;P
[16:45] <didrocks> slangasek: yeah, but as I'm hosting videos as well, I need to have no session at the same time I'm hosting
[16:45] <didrocks> slangasek: or I won't be able to join
[16:49] <kgunn> sil2100: can you reconfig me in silo 3 ?
[16:51] <davmor2> popey: https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1288343
[16:53] <sil2100> kgunn: sure
[16:55] <sil2100> popey, davmor2: huh, funny bug!
[16:55] <popey> confirmed
[16:56] <ogra> [16:56] <davmor2> sil2100: if you have an n10 there is another one that I'm about to type up that is even more fun]
[16:58] <sil2100> davmor2: I just have a mako
[16:58] <sil2100> I might look into that one anyway in my free time
[16:59] <sil2100> Still busy with something else though
[16:59] <ogra> yup, i noticed that one too
[16:59] <ogra> (on the weekend actually ... forgot to file it)
[17:00] <popey> at least we're all consistent
[17:00] <sil2100> kgunn: reconfiguring in progress
[17:01] <didrocks> cyphermox: coming?
[17:01] <cyphermox> yes, just a second
[17:01] <davmor2> sil2100: https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1288348
[17:02] <sil2100> kgunn: reconfigured
[17:02] <sil2100> davmor2: ok, this one is interesting
[17:02] <davmor2> sil2100: only happen on manta I'm assuming due to running in sidestage
[17:03] <ogra> it isnt clear if the sidestage implementation will stay as is though
[17:03] <ogra> (most likely it wont)
[17:04] <kgunn> sidestage impl will change for sure....
[17:04] <kgunn> right edge navigation blows it up
[17:04] <ogra> i wonder fi it makes sense to collect bugs then
[17:04] <ogra> for stuff affected by it
[17:05] <sil2100> I have no way of seeing how sidestage works so I probably won't try fixing this one ;p
[17:19] <rsalveti> kgunn: are you still blocked by platform-api?
[17:20] <sil2100> rsalveti: no, we flushed the silo
[17:20] <rsalveti> awesome
[17:20] <sil2100> rsalveti: so Mir has a silo right now
[17:20] <rsalveti> guess we still need to build it though
[17:25] <didrocks> slangasek: so renamed as per asac request to https://blueprints.launchpad.net/ubuntu/+spec/core-1403-landing-process-touch
[17:26] <didrocks> slangasek: it needs to be on Wednesday apparently. Can you ensure it doesn't move then as I'll need to ensure I have an empty slot in client2 at the same time?
[17:26] <didrocks> or something else will need to host a session in client2 at the same time
[17:28] <asac> yeah please coordinate
[17:28] <kgunn> rsalveti: blocked on myself atm
[17:33]  * didrocks waves good evening
[17:39] <sil2100> ;)
[17:44] <robru-sick> sil2100, is there a way to make the spreadsheet scroll smoothly, instead of locking at the tops of cells? qt52 cell is so tall that I literally can't read the status because it goes off the bottom of my screen
[17:44] <ogra> expense a bigger screen ?
[17:45] <robru-sick> ogra, I have a bigger screen, but it's not hooked up because I'm still sick in bed with my laptop ;-)
[17:46] <ogra> expense a bigger laptop then ::)
[17:49] <robru-sick> ogra, ugh, it's already a 17"! so heavy for travelling.... I've been thinking about buying a smaller one!
[17:49] <ogra> you just need a higher pixel density ;)
[17:51] <sil2100> robru-sick: I don't know of any good way, I also had that problem on my 13 inch laptop screen
[17:52] <robru-sick> sil2100, oh i just noticed if you select the cell, it has a scrollbar. i guess that's ok, but wow ;-)
[17:56] <sil2100> Yeah, but it's irritating
[19:10] <asac> ogra: what is the team that can bump build prio?
[19:10] <ogra> archive admins
[19:10] <asac> ogra: have a link?
[19:10] <ogra> ubuntu-archive
[19:11] <ogra> https://launchpad.net/~ubuntu-archive
[19:32]  * cyphermox -> late lunch
[20:02] <infinity> ogra: launchpad-buildd-admins, actually.
[20:03] <ogra> oops
[20:03] <infinity> (But, as a general rule, we shouldn't be bumping build priorities unless something's crazy urgent... The idea that one person's build is more important than another's is usually ego, not reality)
[20:04] <infinity> And if something's that time-sensitive, I will happily kill in-progress builds to free up resources.
[20:12] <ogra> well, in the image based model when even all landings are blocked one slow build can hold up everyone
[20:52] <bfiller> robru-sick: any idea what's wrong with line 6? (silo-002)
[20:53] <bfiller> robru-sick: sorry, line 17
[20:54] <bfiller> robru-sick: and silo-12 ready for publish
[21:12] <kgunn> bfiller: does yours seem stuck somewhere...?
[21:13] <kgunn> ...i got silo 3 and its been over 3 hours...still waiting on platform-api arm to publish
[21:17] <robru-sick> bfiller, sorry, was afk. you're trying to rebuild silo 2?
[21:18] <robru-sick> bfiller, it looks like basically it's trying to tell you that you already built once successfully, so it's trying to stop you from an accidental rebuild. if you *really* want to rebuild it, you need to check FORCE_REBUILD and IGNORE_STEP
[21:19] <bfiller> robru-sick: ah ok
[21:20] <robru-sick> bfiller, and published 12. keep those qt5.2 fixes coming ;-)
[21:25] <kgunn> robru-sick: is mine still alive ? i mean unity-mir build failed, but that's normal/expected..i always have to rebuild it (inter dependency on platformapi)
[21:25] <robru-sick> kgunn, checking
[21:27] <robru-sick> kgunn, looks like your platform-api is actually a depwait: https://launchpad.net/~ci-train-ppa-service/+archive/landing-003/+build/5662475
[21:27] <robru-sick> not sure why that would pass on i386 and amd64 and then depwait on arm like that. also not sure why citrain thinks it's still building.
[21:28] <robru-sick> kgunn, probably best to just cancel that build job.
[21:28] <kgunn> robru-sick: ack...
[21:28] <kgunn> robru-sick: and then just rekick it ?
[21:29] <robru-sick> kgunn, not sure. how do you normally handle it?
[21:29] <robru-sick> it failed because it didn't have libmirclient-dev > 0.1.6, is that going to be there for the next build?
[21:31] <kgunn> robru-sick: yes...well...now i see mir for arm failed
[21:31] <robru-sick> kgunn, that'll do it ;-) so make sure you resolve that failure before rebuilding (unless it was infrastructural, then a rebuild will probably fix it)
[21:32] <kgunn> robru-sick: so just so i know...when it builds for arm, and runs the unit tests....does it have android gl/display drivers present ?
[21:33] <robru-sick> kgunn, not sure...
[21:33] <kgunn> robru-sick: mmm, can we determine that ? that appears to be the reason for the failure...
[21:33] <kgunn> note..."appears to be"
[21:34] <robru-sick> kgunn, i don't know, sorry. i don't know much about the builders. who would know that? fginther? a launchpad person?
[21:34] <robru-sick> kgunn, theoretically if you depend on something, it'll get pulled in for the build.
[21:35] <kgunn> robru-sick: agreed normally...but these are arm android drivers...
[21:35] <kgunn> hmmm....
[21:35] <kgunn> it does run and pass on our ci
[21:35] <fginther> robru-sick, are we talking about a silo build?
[21:35] <kgunn> fginther: right, silo build for mir failed
[21:35] <kgunn> https://launchpadlibrarian.net/168445165/buildlog_ubuntu-trusty-armhf.mir_0.1.6%2B14.04.20140305-0ubuntu1_FAILEDTOBUILD.txt.gz
[21:35] <robru-sick> fginther, yeah, kgunn was wondering if android gl / display drivers are present in the arm ppa builds
[21:36] <robru-sick> kgunn, what package would provide those? like libhybris?
[21:36] <kgunn> right...libhyrbis is how it uses them
[21:36] <robru-sick> kgunn, or is this like the difference between "building on an ubuntu touch image" vs "building on a generic arm server"?
[21:36] <kgunn> exactly...
[21:36] <robru-sick> hmmmm
[21:37] <kgunn> the unit tests try to render
[21:37] <kgunn> so maybe they're not appropriate to turn on for this ?
[21:37] <kgunn> whereas ci runs on actual hw...
[21:37] <kgunn> i'm kind of guessing here...
[21:37] <robru-sick> kgunn, well I am pretty sure that the arm builders are just generic arm servers, no way launchpad PPA builds are happening inside ubuntu touch. but if you depend on the right packages, it should pull in enough of ubuntu touch to approximate it for most uses.
[21:38] <fginther> robru-sick, kgunn, this is all inside of launchpad. I'm not very familiar on how these builds are configured
[21:38] <robru-sick> fginther, me either, but I know that launchpad predates ubuntu touch by quite some time, and is currently stagnating. I would be *shocked* if I found out that arm ppa builds are happening on live ubuntu touch images ;-)
[21:39] <fginther> robru-sick, me too, I assume these are absolute bare bones armhf environments
[21:39] <fginther> I also don't know if it's virtual or native
[21:39] <robru-sick> kgunn, but if you check the build log, it does pull in libhybris-common1
[21:40] <robru-sick> fginther, I heard a rumour that the silos are native, but typically PPAs are virtual by default
[21:40] <kgunn> robru-sick: fginther ...is there a way to determine how ci & silo is different ?...i mean these same tests pass ci
[21:40] <robru-sick> kgunn, are these tests new? did they ever pass in a silo?
[21:40] <kgunn> but i just saw the same exact failure on my atttempt at a staging recipe
[21:41] <kgunn> ... robru-sick i'm checking that very fact
[21:42] <kgunn> i thot we had them on before in silo, but maybe not
[21:45] <kgunn> robru-sick: mmmm...i think they might have been suppressed....
[21:45] <kgunn> robru-sick: i'm gonna supress & rebuild...
[21:45] <kgunn> sorry...for bothering...
[21:45] <fginther> kgunn, the big differences are that ci uses pbuilder chroots, launchpad uses sbuild.
[21:45] <robru-sick> kgunn, no worries
[21:45] <kgunn> ah!!!....so good there is an answer for silo vs ci
[21:45] <kgunn> does it bother anyone else ??
[21:45] <kgunn> or am i special
[21:47] <fginther> kgunn, I've never heard that specific aspect causing a problem before. In the ci chroots, we also install a few packages by default (like python) which really shouldn't be there. That has caused problems, exhibited by packages failing in LP due to missing dependencies
[21:49] <fginther> kgunn, do you know what is causing the failures? I wouldn't be surprised if CI provides a more open environment when it comes to access to the underlying bare metal, where LP would be more locked down
[21:53] <kgunn> fginther: yeah, basically these integration tests attempt to render something on android gpu drivers...
[21:54] <kgunn> is the drivers aren't there, then these are the tests that would fail
[21:54] <kgunn> so CI as you say must give more access somehow
[21:54] <kgunn> it'd be nice if silo were same as CI (at least in this instance)
[21:55] <kgunn> asac:  ^ ...just something to put on the "think about" list to make silo builds better
[22:01] <fginther> kgunn, eventually CI builds will all be in launchpad
[22:02] <kgunn> woohoo
[22:02] <kgunn> fginther: thanks...
[22:02] <kgunn> btw, how is the weather there? is just cold as hell or what ?
[22:02] <fginther> kgunn, cold is an understatement. This winter is never going to end
[22:03] <kgunn> fginther: you'll appreciate this tx weather...80 degress on Sat, sunday by noon 23
[22:06] <fginther> kgunn, wow, hope it's just cold and no ice
[22:11] <kgunn> we had ice.. back to 50
[23:40] <kgunn> robru-sick: ok...i fixed mir to suppress the tests, it built for arm ok...but not papi seems hung again...
[23:40] <kgunn> dep wait again
[23:40] <robru-sick> kgunn, papi?
[23:41] <robru-sick> kgunn, also, isn't this the usual depwait you see? just kill the one then restart