=== lan3y is now known as Laney
=== Laney is now known as Guest61035
[08:05] <sil2100> jibel, Mirv, davmor2: you guys want to have the meeting today? ;)
=== Guest61035 is now known as Laney
[08:06] <jibel> sil2100, no
[08:06] <jibel> good morning :)
[08:09] <sil2100> Morning!
[08:10] <sil2100> Mirv: anything to discuss from your side?
[08:13] <Mirv> sil2100: nothing in particular. seeing you folks is nice of course, but if there's nothing to discuss... :)
=== _morphis is now known as morphis
[08:32] <oSoMoN> trainguards: can the i386 and amd64 builds of webbrowser-app be re-tried in silo 46 (for both series) ?
[08:32] <sil2100> oSoMoN: sure
[08:32] <oSoMoN> thanks!
[08:33] <oSoMoN> jibel, I’m rebuilding silo 46 with an additional bug fix, it is currently marked as ready for QA in the trello board but I’ll need to revalidate it quickly before it’s actually ready
[08:33] <jibel> oSoMoN, okay, just add a comment on the card
[08:33] <sil2100> Done
[08:33] <oSoMoN> ok
[08:34] <jibel> oSoMoN, otherwise, remove the status "ready for QA" in bileto and a card will be recreated when you change it to ready again
[08:35] <oSoMoN> jibel, I just added a comment, hopefully this will be quick enough that it isn’t picked up by a QE in the meantime anyway
[08:35] <oSoMoN> if it turned out to be more time-consuming than I expected, I’d update the status in bileto
[09:04] <Mirv> oSoMoN: looks ok now, I'm running watch_only on 46
[09:06] <oSoMoN> Mirv, thanks
[09:14] <jibel> sil2100, does phablet-tools has to land in the overlay, shouldn't it be an SRU in vivid?
[09:14] <jibel> sil2100, silo 51
[09:14] <jibel> for reference
[09:20] <sil2100> jibel: from what I know we had a discussion where phablet-tools should be landing
[09:23] <jibel> sil2100, and the conclusion was to land in the overlay,
[09:23] <jibel> s/,/?/
[09:33] <Mirv> jibel: + SDK PPA copy after that, me/bzoltan can handle that
[09:36] <jibel> Mirv, my question was more how do we decide if a package not seeded on the phone goes to the overlay or should be an SRU? in this case phablet-tools.
[09:39] <Mirv> jibel: good questoon... SRU would be the best, although fpr dev tools SDK PPA os just as fine. overlay is unneeded for phablet-tools really, could be just wily too.
[09:40] <Mirv> -typos, walking to lunch. damn ubuntu-keyboard! :)
[09:42] <jibel> morphis, ^ about silo 51. you can land in wily and the SDK PPA. unless there is a reason I miss to land it in the overlay too.
[09:42] <morphis> jibel: ok
[09:42] <morphis> jibel: I think overlay isn't needed
[10:24] <Mirv> morphis: do you want to still do something with 051 or should it be published?
[10:25] <morphis> Mirv: no, can be published
[10:25] <Mirv> morphis: ok, I'll just modify it to be wily only
[10:25] <morphis> Mirv: great
[10:27] <Mirv> morphis: nice fixes, appreciated!
[10:27] <Mirv> and thanks to QA too
[10:28] <morphis> Mirv: yeah, was really time to get this tool improved
[10:40] <oSoMoN> jibel, FYI, silo 46 is now ready for QA validation again (I commented on the trello card)
[10:48] <Mirv> bzoltan_: FYI copying latest phablet-tools for vivid and trusty to SDK Release PPA
[11:18] <Mirv> bah
=== _salem is now known as salem_
=== alan_g is now known as alan_g|lunch
[12:24] <rvr> abeato: Take a look to my comments at https://trello.com/c/BWPvIkY7/2276-269-ubuntu-landing-055-qtubuntu-media-media-hub-jhodapp
[12:53] <bzoltan_> Mirv:  thank you
=== alan_g|lunch is now known as alan_g
[13:01] <sil2100> slangasek: hey! Could you merge in a system-image branch for me?
[13:01] <sil2100> slangasek: https://code.launchpad.net/~sil2100/ubuntu-system-image/server-fix-pd-builds/+merge/272445
[13:09] <sil2100> jibel: ugh, just now I noticed that I answered on a completely unrelated channel, yes, it's like Mirv said ;p geez...
[13:11] <jibel> sil2100, heh
[13:36] <sil2100> barry: hey! Could you merge in https://code.launchpad.net/~sil2100/ubuntu-system-image/server-fix-pd-builds/+merge/272445 ? Added changes as per your comment ;)
=== Guest62641 is now known as balloons
[13:59] <barry> sil2100: sure, i can merge it, but i can't publish it.
[14:00] <sil2100> barry: I'll publish it, no worries :)
[14:04] <barry> sil2100: i made one minor change to the comments, and i'm running the tests locally.  if they pass, i'll commit and push
[14:05] <barry> pep8 unhappiness :(
[14:08] <sil2100> Worked fine here ;)
[14:08] <sil2100>   fast-py34: commands succeeded
[14:08] <sil2100>   congratulations :)
[14:08] <sil2100> PEP8 is not ran as part of this test-suite?
[14:09] <barry> sil2100: it is apparently when you run `tox`
[14:10] <sil2100> What made it unhappy?
[14:11] <barry> sil2100: it's a bunch of the bin scripts and some of the lib/systemimage/testing modules.  i will look at fixing them before i push your branch
[14:11] <sil2100> But I didn't touch those now did I?
[14:11] <barry> sil2100: nope
[14:12] <barry> so clearly the test suite isn't getting run much ;)
[14:12] <sil2100> ;)
[14:12] <sil2100> I'm just running the fast ones, though that runs everything
=== salem_ is now known as _salem
[14:13] <sil2100> barry: hmm... just checked and it looks like fast-py34 also runs PEP8 tests and it doesn't say anything on my local machine
[14:15] <barry> sil2100: well, that's interesting
[14:15] <barry> sil2100: wonder if it's a wily thing?  are you running 15.10?
[14:16] <sil2100> 15.04 still, maybe that's it?
[14:16] <sil2100> test_pep8_clean (systemimage.tests.test_static.StaticTests) ... ok
[14:16] <barry> sil2100: possibly.  but pep8 is the only failures so they should be easy to fix.  i will commit and push your branch, and then do another pep8 fix branch next
[14:16] <barry> sil2100: weird!
[14:16] <sil2100> Thanks, I'll try to publish it at s-i :)
=== _salem is now known as salem_
[14:17] <barry> sil2100: merged
=== ralsina_ is now known as ralsina
[14:45] <nerochiaro> cihelp: is it just me or is jenkins taking forever to run tests on merge requests today ?
[14:54] <dbarth_> o/ hi, i need a trainguard to retry a ppa build failing on a unit test on wily (silo 025)
[14:54] <sil2100> dbarth_: on it!
[14:54] <sil2100> Webbrowser?
[14:54] <dbarth_> the i386 and amd64 builds namely; armhf passed already
[14:54] <dbarth_> sil2100: yeah
[15:01] <sil2100> Rebuilding itself
[15:01] <rvr> alf_: kgunn: Approving silo 28
[15:01] <kgunn> rvr: thanks ....we've got another landing right behind that one :)
[15:08] <fginther> nerochiaro, there are a couple of makos offline. If you're MPs rely on mako testing, that is likely the problem... Assuming they aren't dead for good, they should be up again soon.
[15:09] <nerochiaro> fginther: ok. so if they come back up, i don't need to restart the jobs, they will be taken care of
[15:10] <nerochiaro> ?
[15:10] <awe_> sil2100, cyphermox, question about NM wily landing ( 010 ); it's currently in the UNAPPROVED queue; can one of you explain?  Is there any action needed for me or cyphermox to move fwd?
[15:11] <cyphermox> awe_: no actions from you
[15:11] <sil2100> awe_: wily is now in manual-approve mode
[15:11] <cyphermox> it's up to an archive admin to review, I already mentioned it to infinity.
[15:12] <fginther> nerochiaro, correct. In most cases the devices take themselves offline so as not to impact builds and jobs will just wait until a device is available
[15:12] <awe_> thanks guys
[15:12] <nerochiaro> fginther: thanks
[15:12] <awe_> and thanks for the help fri afternoon cyphermox!
[15:13] <cyphermox> yes
[15:13] <cyphermox> awe_: NM should be top notch on the phone.
[15:13] <fginther> nerochiaro, in a few cases, the devices can fail in the middle of a test in which case it will need to be restarted. These will appear as a failed jenkins job.
[15:13] <awe_> cyphermox, well...we need to land all those changes to the overlay PPA next.  ;)-
[15:14] <cyphermox> yes, of course.
[15:14] <awe_> but yes, it continues to improve
[15:14] <nerochiaro> fginther: also i am having an hard time figuring out what is wrong with the mako failures in thir MR: https://code.launchpad.net/~uriboni/webbrowser-app/topsite-previews/+merge/269771 - i have been told some tests timeout causing the whole to timeout, but that doesn't help me figure out what is actually causing the initial problem
[15:23] <fginther> nerochiaro, I can't help much on those test failures. The device was provisioned successfully with ubuntu-touch/rc-proposed/ubuntu image 241, the packages from the MP were installed, and the screen was unlocked to run the tests. That's about as far as I can diagnose.
[15:24] <nerochiaro> fginther: do you know who might be able to help ? to be clear: i don't need help in fixing the tests, but in figuring out which one is making the whole CI run choke
[15:25] <nerochiaro> fginther: as I understand it, it should not happen. tests that fail should not make the whole fail
[15:26] <fginther> nerochiaro, Maybe I'm ansering the wrong question. Why wouldn't a failing test not make the whole thing fail? Do you expect CI to mark this MP as PASSED instead of FAILED?
[15:31] <fginther> nerochiaro, you can also follow the instructions here for re-creating the CI testing locally: http://ubuntu-test-cases-touch.readthedocs.org/en/latest/
[15:31] <fginther> nerochiaro, testing of MPs is specifically covered here: http://ubuntu-test-cases-touch.readthedocs.org/en/latest/#provisioning-and-executing-autopilot-tests-for-an-mp
[15:32] <nerochiaro> fginther: i would expect it to mark the failing AP test as failed, but not the majority of AP tests as failed (108 over 150, which were passing in previous runs). but I will try your suggestion and see what I can reproduce locally
[15:34] <fginther> nerochiaro, Ah, I understand. One failure should not impact the other tests in this case... One thing to aware of is that CI is running both the webapp_container and webbrowser_app tests, with the webapp_container tests running first
[15:36] <nerochiaro> fginther: i'll keep that in mind
[16:08] <sil2100> kgunn: hey! Can you approve https://code.launchpad.net/~unity-system-compositor-team/unity-system-compositor/0.1/+merge/272394 ?
[16:13] <robru> Mirv: can you copy a vivid version of phablet-tools to https://launchpad.net/~phablet-team/+archive/ubuntu/tools please?
[16:13] <ogra_> robru, why cant you ?
[16:13] <ogra_> arent you in phablet-team ?
[16:14] <ogra_> as the quasi maintainer of phablet-tools you should really be i think :)
[16:14] <robru> ogra_: well somebody deleted the vivid version of the package that I built then published & freed the silo, so...
[16:15] <robru> ogra_: it's not about permissions it's about "please rebuild the package you deleted"
[16:15] <ogra_> ah :)
=== alan_g is now known as alan_g|EOD
[18:06] <boiko> robru: any idea on what went wrong here: https://ci-train.ubuntu.com/job/ubuntu-landing-016-2-publish/107/console
[18:11] <robru> crap
[18:11] <robru> boiko: hang on
[18:13] <renatu> robru, what I need to do to get the debug packages for a specific silo available on apt
[18:13] <robru> boiko: ok I pushed a fix, should be live in 5 minutes.
[18:14] <robru> renatu: not sure, ask infinity
[18:14] <boiko> robru, thanks
[18:18] <robru> boiko: ok try it now
[18:20] <boiko> robru: now it said the silo is dirty, that I need to rebuild messaging-app, I don't remember anything landing in there
[18:20] <robru> hmmm
[18:21] <boiko> robru: or at least it was not showing the silo dirty message when I first tried to publish it
[18:22] <robru> boiko: yeah, that's a known bug, if the silo is dirty and you rebuild only part of the silo it will report 'packages built' even though the silo is technically dirty. I'm just trying to find why it thinks it's dirty
[18:23] <boiko> robru: ah ok, well, the last package rebuilt there was messaging-app anyways
[18:24] <renatu> Ursinha, do you know how I can make the silo/ppa debug packages available on apt list?
[18:26] <robru> boiko: https://ci-train.ubuntu.com/job/cyphermox-test/1160/console your changelog seems to be missing v 0.1+15.10.20150923.1-0ubuntu1 which is in wily, apparently you never rebuilt since publishing whatever silo that came from on spet 25)
[18:26] <robru> boiko: so it seems no mistake, you really do need to rebuild.
[18:26] <boiko> robru: oups, ok, my bad then
[18:26] <boiko> robru: yep, sorry about that
[18:26] <robru> boiko: no worries, glad this check saved us from clobbering your previous release ;-)
[18:27] <boiko> :)
[21:09] <dobey> trainguards: can someone please cancel all the builds for https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+sourcepub/5415761/+listing-archive-extra ? seems the tests are hanging for some reason :(
[21:09] <robru> dobey: on it
[21:10] <robru> dobey: ok done
[21:11] <dobey> robru: thanks
[21:11] <robru> you're welcome
[22:04] <tedg> robru: Do you by change have a script that copies source package from one repo to another?
[22:04] <tedg> by chance
[22:04] <robru> tedg: nope I just use the LP web interface when I need to do that
[22:05] <robru> tedg: IIRC there's a copy-package tool in some kind of archive-tools repo though
[22:06] <robru> tedg: yeah https://launchpad.net/ubuntu-archive-tools
[22:12] <tedg> robru: Cool, thanks!
[22:12] <robru> tedg: you're welcome
=== salem_ is now known as _salem