=== renato_ is now known as Guest30310
[02:04] <imgbot> === trainguard: IMAGE 116 building (started: 20140707 02:05) ===
[03:34] <imgbot> === trainguard: IMAGE 116 DONE (finished: 20140707 03:35) ===
[03:34] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/116.changes ===
[06:03] <mvo> good morning
[06:18] <Mirv> so is choo choo now obsolete basically because of the queuebot?
[06:19] <Mirv> hmm I guess trainguards get only pinged for new lines on choo-choo
[06:19] <Mirv> oh, no that was also there above, I should just add a hilight for "Landings"
[06:21] <Mirv> and, good morning to mvo too
[06:21] <mvo> hey Mirv, good morning :)
[08:11] <Saviq> cihelp, hey, a lot of the jobs that are failed in http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-mako/ were due to them getting stuck, e.g. http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-mako/1869/console this one just looped, while others were stuck in "recording test results"
[08:11] <Saviq> this one is looping now: http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-mako/1889/consoleFull
[08:11] <Saviq> this mako is stuck in flashing, too: http://s-jenkins.ubuntu-ci:8080/computer/mako-04cbcc545f5328a5/?
[08:12] <ogra_> we seem to have a lot of non-running smoketests too on mako
[08:12] <ogra_> s/have/have had/
[08:19] <psivaa> ogra_: the tests on mako are running now. unlock unity issue: http://pastebin.ubuntu.com/7759153/
[08:19] <ogra_> yeah, smelled like it
[08:19] <ogra_> thanks for confirming
[08:20]  * ogra_ goes afk to make coffee
[08:30] <sil2100> ogra_, davmor2, psivaa: be right there
[08:32] <davmor2> popey: where are you?
[08:59] <sil2100> Now time to look for my charger...
[08:59] <mvo> sil2100: good luck
[08:59] <Mirv> I'll remove the Qt 5.3.1 line for now. If I have time do some test builds, I'll do them outside of the silo system.
[09:03] <alan_g> cihelp: something is wrong with http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-autolanding/ -  it is running the identical job repeatedly (858 is the same as 857, ..., 847, 846 and 843)
[09:05] <psivaa> Saviq: alan_g: will take a look at them in a little bit
[09:10] <vila> alan_g, psivaa: http://s-jenkins.ubuntu-ci:8080/job/generic-land/23670/console some branch setup is borken
[09:16] <alan_g> vila: psivaa - I tried to reproduce (branched the target, merged the proposed) but don't see a problem. Any suggestions?
[09:17] <vila> alan_g: doing the same for the MP branch and  merging the target itself to catch up
[09:18] <vila> alan_g: that "ghost" is probably caused by some weird shuffling at some point in the MP branch history
[09:34] <psivaa> alan_g: looks like your new merging helped
[09:35] <psivaa> http://s-jenkins.ubuntu-ci:8080/job/generic-land/23672/console
[09:36] <alan_g> psivaa: Good. (We could do with better failure information though.)
[09:38] <seb128> fginther, reasking here, since there are more CI people on this channel
[09:38] <seb128> fginther, hey, do you know why jenkins/CI doesn't run on https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/1297418-apply-new-designs-to-background-panel/+merge/223571 ?
[09:39] <seb128> seems like ~jonas-drange needs to be added to some jenkins-authorized-list?
[09:39] <seb128> cihelp ^
[09:42] <bzoltan> sil2100: Mirv: i do not have upload rights to the silo16, but I need to push there the synced -gles package for the UITK.
[09:43] <sil2100> Mirv: ^ can you help out pushing that to silo 16?
[09:43] <sil2100> bzoltan: if you give us the source package, someone from our team will push it to the PPA
[09:46] <psivaa> Saviq: those jobs should now be un-stuck
[09:46] <bzoltan> sil2100: what if I push that source to somewhere where you guys can copy
[09:50] <bzoltan> sil2100: Mirv: here is the package -> https://launchpad.net/~bzoltan/+archive/qt5/+sourcepub/4278773/+listing-archive-extra
[09:51] <bzoltan> Since the -gles is a mandatory add-on since last week I think it would be easier if i could upload that source to the build silo. Otherwise the whole idea that I make that sync is rather pointless.
[10:02] <psivaa> sil2100: brendand: ogra_: the messaging app tests failed again on the second run: http://ci.ubuntu.com/smokeng/utopic/touch/mako/116:20140707:20140625/8902/messaging_app/
[10:03] <brendand> psivaa, i couldn't reproduce them locally though
[10:04] <sil2100> bzoltan: ok, makes sense
[10:04] <sil2100> psivaa: hmmm
[10:04] <sil2100> Ok everyone, I have to jump out to the tax office and then for lunch, so be back soon
[10:13] <Mirv> bzoltan: uploading
[10:29] <bzoltan> Mirv: danke
[10:44] <psivaa> brendand: so, i reran again with a fresh flashing on a different device and the failures still there
[10:45] <psivaa> brendand: so basically the failures observed in 3 different devices.
[10:45] <psivaa> brendand: not sure what more i could do
[10:45] <brendand> psivaa, i'll try again
[10:46] <bzoltan> ogra_: thanks for the lengthy mail... I start to fix the SDK tools
[10:47] <ogra_> bzoltan, awesome ... note that we need to land everything together though :)
[10:48] <bzoltan> ogra_: I know. It is nothing new for me. With the UITK we sync with 3-4 apps before each landing.
[10:49] <ogra_> :)
[10:54] <brendand> psivaa, same failures in all cases, or varyinf?
[10:55] <brendand> s/varyinf/varying/
[10:57] <psivaa> brendand: most of them are same, one or two appear to be flaky
[11:00] <bzoltan> Mirv: could you please help with this? ERROR:root:ubuntu-ui-toolkit-gles was not in the initial list of components for that silo. You can't reconfigure the silo yourself. Please ask the landing team to reconfigure it for you.
[11:00] <sil2100> bzoltan: you have to add it to the list of additional sources to land
[11:00] <sil2100> bzoltan: we might need to reconfigure it for you
[11:00]  * sil2100 takes a look
[11:01] <bzoltan> sil2100: I added it in the sheet
[11:01] <sil2100> bzoltan: reconfiguring then!
[11:04] <bzoltan> sil2100: thanks
[11:04] <sil2100> bzoltan: should be ok now - could you try?
[11:05] <sil2100> bzoltan: did you have that package copied already? Or do you need assistance?
[11:27] <sil2100> Mirv: did you have any precautions on publishing silo 11? Or you just didn't move it and I can do that normally?
[11:29] <Mirv> sil2100: I was just slightly cautious in running to publish anything on my first day :)
[11:29] <Mirv> it looked good, though
[11:30] <Mirv> sil2100: plus I didn't know the history of locked components so I thought you knew better if it was now really good to go (like it probably is)
[11:30] <sil2100> Mirv: no worries ;)
[11:30] <sil2100> I'll publish it, just wanted to know if there were any precautions
=== sil2100 changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: #113 promoted | CI Train Sheriff: mvo, sil2100 | Known issues: The spreadsheet is extremely slow, http://bit.ly/VI2SEl knows the statuses before the spreadsheet does.
[11:37] <mandel> sil2100, morning! any idea why would jenkins complain about https://code.launchpad.net/~mandel/unity-scope-click/udm-rebuild/+merge/225487 generating and empty changelog when the changelog was edited?
[11:37] <sil2100> mandel: let me take a look
[11:41] <mandel> sil2100, thx
[11:42] <ogra_> must be the "if $last_commiter = "manuel.delapena@*"; then Fail; fi" code in the CI train :)
[11:43] <sil2100> ;)
[11:47] <sil2100> mandel: hmmm, I see something strange here happening even
[11:49] <sil2100> mandel: since when looking at your merge, I see the generated diff mentioning 0.1+14.10.20140625-0ubuntu1 as the previous version, where lp:unity-scope-click has 0.1+14.10.20140704-0ubuntu1 as the final one
[11:49] <sil2100> Too bad we don't have the sync with the backend anymore
[11:50] <sil2100> hm, or maybe we do?
[11:51] <mandel> sil2100, you think is due to the version?? that can be change easily
[11:53] <sil2100> Not sure, need to check what the heck the backend is doing, as it should not be a problem for CI Train
[11:54] <mandel> sil2100, well, I'm going to merge with trunk and give it a go
[12:02] <sil2100> The backend looks really strange as well actually
[12:04] <sil2100> mandel: yeah, it's just a first-guess, but let's try
[12:06] <sil2100> mandel: could you give me a sign once you rebase on trunk and retry?
[12:07] <mandel> sil2100, is in the process
[12:11] <Mirv> sil2100: I've a problem reconfiguring the qtdeclarative silo: https://ci-train.ubuntu.com/job/prepare-silo/913/console - does that make any sense?
[12:11] <sil2100> Mirv: looking!
[12:11] <sil2100> ogra_: in the meantime, can you +1 this? Just a symbol added: https://ci-train.ubuntu.com/job/landing-011-2-publish/lastSuccessfulBuild/artifact/packaging_changes_dbus-cpp_3.1.0+14.10.20140701-0ubuntu1.diff
[12:12] <sil2100> (it's in main so I need to ask core-devs)
[12:12] <Mirv> sil2100: thanks. I wonder if it's trying to split an empty string or something, and this is the first time a silo with only "other sources" is being reconfigured..
[12:14] <sil2100> Mirv: which line is it from in the spreadsheet?
[12:14] <sil2100> 24?
[12:14] <sil2100> Mirv: I'll try to reconfigure now
[12:15] <Mirv> sil2100: 24 yes
[12:15] <ogra_> sil2100, looks fine, ACK ...
[12:15] <sil2100> AH!
[12:16] <sil2100> Mirv: hah, see the problem now ;)
[12:16] <sil2100> Mirv: look at where you added the comment ;)
[12:16] <sil2100> Mirv: you added the comment to the MP list field!
[12:16] <Mirv> sil2100: oh no!!! :)
[12:16] <Mirv> silly silly me
[12:16] <Mirv> sil2100: thanks, sometimes it requires another pair of eyes..
[12:17] <Mirv> sil2100: yep, worked
[12:18] <sil2100> No problem, 'typos' like these happen!
[12:18] <sil2100> ogra_: thanks!
[12:20] <sil2100> mvo: ok, so we need to poke the upstream developer about this one, maybe these are only some leftovers in the configuration
[12:22] <sil2100> mandel: it seems we'll have to rebuild packages in silo 11... I see that the packages there are out-of-date
[12:24] <mandel> sil2100, yep, doing it
[12:24] <sil2100> mandel: thanks!
[12:24] <sil2100> mandel: what about silo 12? Does it work now, or still the same problem?
[12:26] <mandel> sil2100, waiting for it to give an error :)
[12:27]  * sil2100 crosses his fingers
[12:27] <sil2100> ;)
=== renato_ is now known as renato__
[12:59] <bzoltan> Mirv: sil2100: The UITK in the silo16 is good to land in my opinion. We have narrowed down the problems -> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/landing_0307/+merge/225476/comments/543146 popey has promised to push an update of the terminal, short, clock to the store and the address-book fix is in the staging branch -> http://bazaar.launchpad.net/~phablet-team/address-book-app/staging/revision/207 the last standing UITK 
[13:00] <bzoltan> renato__:  do you have a plan to merge the address-book staging to the trunk today?
[13:00] <renato__> bzoltan, I will try
[13:01] <bzoltan> renato__: cool, thanks. We have a huge landing of the UITK and I would love to get it done today.
[13:01] <renato__> nice
[13:03] <sil2100> bzoltan: looks nice, I'm a bit worried about the failures that could not have been reproduced, but I guess there's risk like that always
[13:03] <sil2100> bzoltan: once the address-book-app fix is staged for release in a silo I think we should be fine on releasing UITK
[13:03] <bzoltan> sil2100:  those failures are gone too.
[13:04] <bzoltan> sil2100: one glitch was that the UITK theme package was not pulled by the UITK package and that messed up all the headers in many apps. Now it is all fine
[13:53]  * sil2100 jumps out to do some lunch
[13:56] <bfiller> sil2100: need a silo for line 26 when you get a chance
[14:34] <brendand> sil2100, the webbrowser issue is fixed!
[14:34] <brendand> \o/
[14:34] <sil2100> brendand: HOLY SHIT
[14:35] <sil2100> brendand: how?!
[14:35] <sil2100> WHERE?! :D
[14:35] <brendand> THERE!
[14:35] <brendand> as dumb as  unitialized variables, that's it...
[14:58] <sil2100> charles: hey! Are you upstream for indicator-location by any chance?
[14:58] <charles> sil2100, yep
[14:59] <sil2100> charles: since some images we see this LP: #1338610
[14:59] <ubot5> Launchpad bug 1338610 in Indicator Location "indicator-location crashing during default, sdk and click_image_tests tests on smoketesting" [Undecided,New] https://launchpad.net/bugs/1338610
[14:59] <charles> !
[14:59] <sil2100> charles: the crash files *might* be corrupted, but who knows... anyway, a strange thing
[15:00] <sil2100> charles: doesn't seem to be affecting anything, but seems a bit odd that it's crashing at such a place ;)
[15:00] <charles> indicator-location is one of the simplest pieces of code. I'm amazed there's a crasher in there
[15:00] <charles> ie, it's just a couple of toggle menuitems and literally that's it
[15:00] <sil2100> Maybe the cause is somewhere else and it's just generally causing the 'first thing' to crash - but we've seen it reproducible since 113
[15:02] <charles> sil2100, thanks. by any chance do those .crash reports get retraced by the system somewhere? or should I run apport-retrace on them?
[15:03] <sil2100> charles: sadly these need to be retraced manually... thanks for looking into it!
[15:03] <charles> no worries
[15:07] <davmor2> sil2100: in a recent email you said that there are customizable alarms how do you mean? are you talking alarm tone is so how do you change it?
[15:11] <sil2100> davmor2: it was for this to work: https://bugs.launchpad.net/indicator-datetime/+bug/1318997
[15:11] <ubot5> Ubuntu bug 1318997 in Ubuntu Clock App reboot "Provide a way to change alarm sound" [High,In progress]
[15:16] <davmor2> sil2100: ah right so there is a way you can as long as you know how to hack the api via the terminal :D
[15:16] <sil2100> That's the Ubuntu way!
[15:17] <davmor2> sil2100: yeah we're not on the desktop now you know :P
[15:19] <bzoltan1> bfiller:  the AP tests of the address-book app from the silo5 are all OK
[15:19] <sil2100> Bah ;)
[15:20] <bfiller> bzoltan1: great, you can mark it tested then
[15:20] <bfiller> thank you
[15:20] <bzoltan1> bfiller: thank you and to renato__ :)
[15:21] <bzoltan1> sil2100: Mirv: asac: the new UITK from the silo16 is good to go. It has debian/control change so it will require an extra step to land.
[15:21] <sil2100> o/
[15:22] <sil2100> ogra_: could we maybe kick a new image before releasing silo 16 (UITK)?
[15:22] <ogra_> sil2100, sure, right after my current meeting
[15:22] <sil2100> ogra_: let's do it after/right-before our meeting
[15:22]  * bzoltan1 hugs ogra_
[15:23] <ogra_> sil2100, right, that is when my current meeting ends ;)
[15:23] <sil2100> bzoltan1: so expect UITK in tomorrow's image
[15:23] <bzoltan1> sil2100: ogra_: remember that we need there the new address-book from the silo5 and the new terminal, clock, shorts apps from the store.
[15:24] <sil2100> Thanks for working hard on making it as safe as possible
[15:24] <bzoltan1> popey: have you pushed the new apps?
[15:27] <popey> bzoltan1: not yet
[15:27] <popey> wont be till a bit later this evening
[15:37] <Chipaca> ogra_: hi :Ð
[15:44] <imgbot> === trainguard: IMAGE 117 building (started: 20140707 15:45) ===
[15:48] <sil2100> brendand: so wait... did the fix for webbrowser land already? ;) WIll we have it in image 117?
[15:48] <brendand> sil2100, nooo
[15:48] <sil2100> :<
[15:54] <brendand> sil2100, still waiting for a review from ricmm
[15:56] <davmor2> sil2100: was anything fixed in 117? :D
[15:57] <ogra_> davmor2, he wanted to have a stop-gap before landing UITK and friends
[15:57] <sil2100> davmor2: no ;p But it wasn't supposed to be a bugfixing image! THe bugfixing image is next week ;) TOday was feature image!
[15:57] <sil2100> j/k, actually there wasn't many features today even
[15:57] <ogra_> Chipaca, i'll get to it, promised ...
[15:58] <ogra_> (damn i'm not making myself look good ...)
[15:58] <davmor2> sil2100: fair enough, I'm off next week so I care not for bug fixing :P
[15:58] <sil2100> Yeah, and this will actually fix that single UITK failure we're having as a blocker
[15:58] <sil2100> pff ;)
[15:58] <ogra_> davmor2, who approved that !!!!!
[15:59] <bzoltan1> popey:  OK, thanks. It will be important by the next image validation
[15:59] <davmor2> ogra_: My Boss.  It's battery re-charging ready for the Sleepless nights of testing to get to rtm
[16:00] <ogra_> insane
[16:03] <sil2100> robru: hi!
[16:04] <robru> sil2100, heya
[16:04] <sil2100> robru: meeting!
[16:04] <sil2100> plars: will you pop up at the meeting?
[16:04] <plars> sil2100: I have a previous call that is running over, will be there shortly
[16:04] <plars> sil2100: was message_app new failures discussed this morning already?
[16:05] <sil2100> plars: yeah, I mean we looked at those and brendand was trying to reproduce but with no luck
[16:05] <plars> sil2100: odd, I see flo had almost the same number of failures on it
[16:06] <brendand> sil2100, there's a strong possibility it's also rotation related
[16:09] <popey> bzoltan: understood.
[16:22] <xnox> chihelp: is it just me, or http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-sbuild/lastBuild is down?
[16:22] <xnox> is that the right URL for private jenkins that is running ADT tests?
[16:25] <cjwatson> works for me
[16:25] <cjwatson> you'll need an appropriate VPN of course
[16:26] <cjwatson> xnox: incidentally the latest failure was clearly transient so I mashed retry on ti
[16:26] <cjwatson> *it
[16:27] <xnox> cjwatson: i used to have appropriate VPN.
[16:27] <xnox> cjwatson: yeap, i wanted to retry - saw the transient error on the public instance.
[16:27]  * xnox goes to check my vpn setup.
[16:28] <xnox> resolvconf went mad, now *.ubuntu-ci urls work again.
=== robru changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: #113 promoted | CI Train Sheriff: robru | Known issues: The spreadsheet is extremely slow, http://bit.ly/VI2SEl knows the statuses before the spreadsheet does.
=== alan_g is now known as alan_g|EOD
[17:19] <imgbot> === trainguard: IMAGE 117 DONE (finished: 20140707 17:20) ===
[17:19] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/117.changes ===
[17:21] <ogra_> popey, ugh ... the debugging tools add 22MB to the tarball ... i think we need to cut that back a bit again
[17:22] <popey> oof
[17:22] <ogra_> i suspect thts libc6-dbg which is being pulled in by valgrind ... and iirc cjwatson warned that might be big ...
[17:22] <rsalveti> wtf
[17:22] <rsalveti> yeah
[17:23] <rsalveti> do we want valgrind by default?
[17:23] <rsalveti> from that list I'd just add strace, but still
[17:23]  * ogra_ unseeds valgrind ... i guess the reast can stay til RTM cleanup
[17:23] <sil2100> o/
[17:23] <rsalveti> who asked to add such tools by default?
[17:23] <bzoltan> cjwatson: may i ask you for a quick check on the UITK package in the silo16. We have changed the debian/control file and so it needs an extra eye.
[17:23] <popey> me
[17:23] <ogra_> rsalveti, we discussed it in the landing meeting last week
[17:23] <popey> i dont mind losing valgrind
[17:23] <ogra_> rsalveti, its only temporary to make debugging a bit easier
[17:23] <rsalveti> cool, great then
[17:24] <ogra_> nothing we want to keep for RTM
[17:28] <rsalveti> brb
[18:02] <kdub_> I've gotten this failure 2x now... https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/599/console
[18:02] <kdub_> is there something I have to do to correct? the failure looks like some sort of timeout error
[18:10] <robru> kdub_, not sure, did you read `bzr help criss-cross`?
=== robru changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: robru | CI Train Status: #113 promoted | CI Train Sheriff: robru | Known issues: The spreadsheet is extremely slow, http://bit.ly/VI2SEl knows the statuses before the spreadsheet does.
[18:12] <kdub_> robru, the other mir jobs didn't have a problem with the merging https://code.launchpad.net/~kdub/mir/mcla-registrar-cleanup/+merge/224939
[18:13] <kdub_> maybe I'll merge devel again and see
[18:13] <robru> kdub_, they also didn't have a timeout ;-)
[18:13] <robru> fginther, hey can you take a look at this? ^^ not sure why this job is failing
[18:14] <fginther> robru, looking
[18:14] <kdub_> thanks robru & fginther
[18:15] <robru> kdub_, my guess would be to discard your branch, start over with a fresh branch of devel, apply your changes in a single commit, and submit that instead. but let's wait for fginther's input before acting on that...
[18:22] <fginther> kdub_, robru, I understand the criss-cross message and why it happens, I don't understand the timeouts (makes me suspect that bzr is trying to access an alternative source that is firewall blocked).
[18:23] <robru> fginther, the way I was reading it, i thought the criss-cross was an error condition that caused the merge not to complete which caused something else to time out waiting for it. is that not the case?
[18:23] <kdub_> criss-cross merges can succeed
[18:23] <fginther> robru, it worked when I did it locally on my desktop
[18:24] <kdub_> maybe I'll merge in the target branch again and then see if works on the third try
[18:24] <robru> hmmm
[18:27] <kdub_> well, we'll see if that works.. let you know in 4 hours
[18:29] <robru> kdub_, k, sorry i didn't know more
[18:30] <kdub_> robru, np, thanks for the help (fginther too)
[18:47] <cjwatson> bzoltan: seems ok
=== josharenson1 is now known as josharenson
[19:09] <bzoltan> cjwatson: Thanks
[19:21] <bfiller> robru: silo 5 will need to be released after the ui-toolkit lands or the address-book AP tests will fail
[19:21] <bfiller> robru: bzoltan did the testing on that
[19:22] <robru> bfiller, ok, uitk is in proposed, waiting for it to land before I release anything else.
[19:22] <robru> bfiller, you got silo1 btw
[19:31] <plars> sergiusens: how far off is a --password option for udf?
[19:33] <plars> ogra_: sergiusens: and just out of curiosity, can we expect any problems with phablet-config once the developer-mode, and adb as phablet user is enabled?
[19:47] <elopio> ping robru. I need help from ci to get a keyring withoug a password on the jenkins machines.
[19:47] <elopio> https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1338714
[19:47] <ubot5> Ubuntu bug 1338714 in Online Accounts setup for Ubuntu Touch "On desktop, we need a password-less keyring for autopilot tests" [Undecided,Confirmed]
[19:48] <elopio> can you put it on the CI roadmap for: as soon as possible :)
[19:49] <robru> fginther, ^^ you know anything about this?
[19:54] <fginther> elopio, can you provide an example of the keyring file to use and it's path?
[19:55] <elopio> fginther: let me see... I'll start a vm.
[19:55] <elopio> dobey: any chance you have the puppet code at hand?
[19:56] <fginther> elopio, it may be possible to put it in place when the test bed starts up and it just works
[19:56] <dobey> elopio: i don't
[19:57] <dobey> i think the location is ~/.local/share/keyrings/default.keyring
[19:57] <dobey> it might be login.keyring there isntead
[19:57] <dobey> not sure at this point
[19:59] <dobey> you can just open seahorse on your laptop or workstation and create a new keyring named "foo" or whatever, with no password, then copy that file to the right place in the vm/config
[20:01] <dobey> fginther: is puppet being used with jenkins to set up these instances?
[20:10] <sergiusens> plars: I expect problems with anything out of phablet-tools that calls adb directly; ogra_ should take care of everything else
[20:11] <brendand> ogra_, do you want to try my patched version of qtubuntu-sensors and see if it fixes those rotation issues you saw with web apps?
[20:12] <brendand> ogra_, this is the branch : lp:~brendan-donegan/qtubuntu-sensors/bug1337284
[20:13] <brendand> robru, can i get a silo for an unmerged branch?
[20:13] <fginther> dobey, no, lp:otto is used which essentially creates an lxc from a desktop ISO with the ability to override files in the image
[20:14] <dobey> ah ok
[20:14] <fginther> dobey, I'm not quite sure how it would handle a keyring file under ~/
[20:14] <dobey> fginther: well, what user is the autologin happening for?
[20:14] <fginther> dobey, ubuntu
[20:16] <dobey> should be fine as long as it has the right filename in the right location, and it's done before the login happens. it doesn't need to be replaced every time the test runs i don't think. just needs to be placed there when the lxc is created
[20:17] <robru> brendand, I'm not sure what you mean. silos cannot be assigned for *merged* branches. but I still need an MP for it
[20:17] <dobey> or the other option is to just not use the keyring backend for online-accounts
[20:19] <dobey> fginther, elopio: so just making sure "signon-keyring-extension" is not installed, should give you a working test without all the keyring unlock and creation hassle
[20:19] <fginther> dobey, I *think* that's compatible with what otto is doing, but there's some risk that I'm missing something in my understanding of how otto works
[20:19] <robru> brendand, I mean, like, by definition all of the silos I assign are for unmerged branches.
[20:19] <fginther> dobey, elopio, how would this test be constructed using autopkgtest?
[20:19] <robru> brendand, so just put your request in the spreadsheet and I'll assign it like I do for all other silos.
[20:21] <dobey> fginther: oh, hmm. i am not sure it could be run as a dep8 test without isolating it away from needing to creat an online account
[20:22] <fginther> dobey, elopio, I believe dep-8 allows specification that a test 'breaks-testbed', that might provide a mechanism for either removing packages or copying in a default keyring file
[20:23] <fginther> might provide a solution
[20:23] <dobey> that might work if we can guarantee it will only ever be runnable inside a chroot/vm, and not on a user's live system
[20:24] <dobey> i don't recall if dep8 provides that guarantee though
[20:24] <elopio> fginther: I'm not sure, but the online_accounts_ui have the autopkgtests and they have been running.
[20:25] <fginther> dobey, I'm no expert myself. I don't know if that's sufficient to keep a user from doing something bad
[20:25] <elopio> the control file doesn't show anything weird:
[20:25] <elopio> Depends: @, autopilot-desktop (>= 1.5.0+14.10.20140526), python3-evdev, dbus-x11, xvfb
[20:25] <elopio> Restrictions: allow-stderr
[20:25] <elopio> it just doesn't start lightdm or unity, I suppose
[20:26] <dobey> elopio: i don't think online accounts tests are actually creating accounts, are they?
[20:26] <fginther> hmmm
[20:26] <elopio> dobey: they are creating a fake login account.
[20:26] <dobey> elopio: for one, i think all the online accounts plug-ins are in a separate source package
[20:26] <dobey> elopio: a simple password account?
[20:26] <elopio> dobey: yes.
[20:31] <elopio> dobey, fginther: ok, confirmed it works
[20:31] <elopio> the path is ~/.local/share/keyrings
[20:31] <elopio> let me upload the files needed.
[20:40] <elopio> fginther: I attached the files to the bug https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1338714
[20:40] <ubot5> Ubuntu bug 1338714 in Online Accounts setup for Ubuntu Touch "On desktop, we need a password-less keyring for autopilot tests" [Undecided,Confirmed]
[20:40] <elopio> dobey: looks right?
[20:44] <dobey> elopio: that should work yes. my main concern is that we don't make it easy for developers to break their systems by running these tests on them
[20:45] <elopio> dobey: yes, this shouldn't be on the branch.
[20:45] <elopio> on the branch, if the dev has the keyring unlocked, it will just pass.
[20:46] <elopio> if it is locked, it will get stuck for like 30 seconds, giving change for the dev to unlock it.
[20:46] <elopio> if nobody is looking, it will just fail.
[20:46] <brendand> robru, where's the spreadsheet?
[20:47] <elopio> dobey: we are also trying to patch the home during the test run. So at that point, we might put an empty keyring on the test home.
[20:47] <elopio> but for now, that's causing the phone to die in many weird ways.
[20:48] <dobey> elopio: it would be nice if a custom signond instance could be spawned with a specific backend to be used, and a custom directory path to write to, for testing
[20:49] <elopio> dobey: how can we tell online accounts to use the custom signond ?
[20:50] <elopio> it will just use the one running?
[20:51] <dobey> elopio: we'd spawn a private dbus-daemon for the session bus, and run things under that
[20:52] <elopio> dobey: sounds good, but I need to research more things for that. First, get this running. Then, export the temp home, and then private bus and daemon.
[20:53] <tedg> robru, Can you please reconfigure silo 4?
[20:53] <dobey> elopio: sure. was just saying "it would be nice if…" ;)
[20:56] <elopio> dobey: we have many many problems because the test environment is not properly isolated. So it's more than "nice to have".
[20:56] <dobey> elopio: oh. i know all too well about problems with tests due to poor isolation :(
[20:57] <dobey> also, "dead"lines
[20:58] <dobey> i think i'll just start wearing a dia de las muertos costume on freeze days
[20:58] <robru> brendand, oops, sorry: https://docs.google.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&usp=sharing
[20:59] <robru> tedg, done
=== robru changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: #113 promoted | CI Train Sheriff: robru | Known issues: The spreadsheet is extremely slow, http://bit.ly/VI2SEl knows the statuses before the spreadsheet does.
=== robru changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: #113 promoted | CI Train Sheriff: robru | Known issues: http://bit.ly/VI2SEl knows your silo status before the spreadsheet does.
[21:02] <elopio> dobey: jajaja. Lets stop calling them freeze days, lets just call them days.
[21:04] <tedg> robru, Thanks
[21:05] <robru> tedg, you're welcome
[21:05] <brendand> robru, can you check the bottom of the sheet and make sure i haven't missed anything/put anything stupid in?
[21:05] <brendand> robru, first time i've done this
[21:05] <robru> brendand, no worries
[21:06] <robru> brendand, looks good, just set "ready:yes" (cell I29 to 'Yes')
[21:19] <rsalveti> robru: hey, can I get a silo for line 30?
[21:21] <robru> brendand, do you know how to build your silo?
[21:21] <robru> bzoltan, so uitk got stuck in proposed, no idea what the failure is here: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/lastBuild/?
[21:32] <brendand> robru, https://ci-train.ubuntu.com/job/landing-014-1-build/build?delay=0sec
[21:32] <brendand> robru, what do i need to fill in there?
[21:32] <robru> brendand, nothing for the first build. those options are only to resolve problems that may come up later. first build is always with a blank form
[21:34] <robru> bfiller, please fill in your landing description in A31
[21:34] <bfiller> robru: doing that now
[21:34] <robru> also we're out of silos
[21:34] <robru> sorry
[21:34] <bfiller> np
[21:34] <brendand> robru, won't i definitely need 'allow_unapproved'?
[21:35] <robru> brendand, is your merge unapproved? ;-)
[21:35] <brendand> robru, yes
[21:35] <robru> brendand, then I suppose you'll need that. but typically your merge should just be approved.
[21:36] <brendand> robru, sergiusens asked me to do this - easier to test this way i guess?
[21:36] <robru> brendand, yeah, silos are pretty handy for testing.
[21:36] <robru> brendand, the merge step is a manual one, approving the MP won't make it automatically land
[21:38] <brendand> robru, i think i started one, but didn't seem to get a confirmation?
[21:39] <robru> brendand, if you're still lookinga at the form then it didn't submit.
[21:39] <robru> brendand, the first time you click build, it redirects you to SSO login, which redirects you back to the form, and does not start the build.
[21:42] <brendand> robru, i'm missing a permission? Job/build
[21:44] <robru> ugh
=== renato_ is now known as Guest32432
=== Guest32432 is now known as renato__
[21:48] <brendand> robru, i'll need to pick this up tomorrow. unless you kick off the build for me?
[21:48] <robru> brendand, yeah ok. I need to figure out what team to put you in for that permissions
=== Ursinha is now known as Ursinha-afk